Altirra 1.9 released

[MEtalGuy66]

Add emulation of Bob Puff's MULTIPLEXER so that you can run 9 sessions of ALTIRRA, each emulating a BBS NODE, and use Steve Carden's TCP/IP EXPRESS BBS software to run an 8-node BBS...

[flashjazzcat]

It pulls about 18%-20% of avg. CPU usage on my dual-core HDMI (Nvidia) Dell Studio and by loading one core about 50% more than the other. All this with Artifacting TURNED OFF. This laptop runs Win7-64, in dual-screen virtual desktop (quasi 720p on its screen, and 1080p on the primary screen) and it is certainly tuned for emulator-usage (it eventually ends with a 42-process list, 18%-19% of memory usage (530MB of overall ram usage), and a 0% CPU (or fractionals below 1%) usage after fully booting, running all of Windows service/maintenance stuff, and unloading all possible Win-bloatware from RAM, except antivirus which STAYS ON permanently. As an example, MAME-UI64 (which I use extensively) chews-up 12% to 25% in most Z80-emulations, all pretty evenly distributed across both cores.

Altirra is using about 35% of the CPU time on my machine, but it's this difference in auto-repeat speed which really has me bugged. KEYREP is set at 5 in PAL mode and 6 in NTSC mode (as one might expect), but while keys appear to repeat a roughly 10 per second in NTSC mode, the repeat is noticably slower in PAL mode.

Edited May 26, 2011 by flashjazzcat

[Keatah]

Ohh wow!! The source for Altirra is available! How cool is that? Now I can make my own menu structures with ease! ..with organizing my boatload of images and roms and disks from the early days.

 

NOW;

I've been curious to know about the high cpu usage you folks have been experiencing, even on your dual core machines. I've noticed a slight speed change between the ntsc and pal key repeat rates. But I also only get about 30%- on average CPU usage on a single-core 1.7GHz Pentium-M 735 (dothan). And to top it off, this is with integrated graphics from intel, as we all know, not the best of GPU's by any means.

 

My framerate bounces around, from like 59.7 to 60.1 .. I'll be experimenting around with all sorts of options both in my XP o/s and in Altirra to see what, if anything, affects this. I would like to somehow see a rock-solid 60fps.

 

But still, a tip of the hat to phaeron for putting this absolutely kick-ass program together for the community. Honestly, really, a few years ago, I thought it tacky and sucky for a number of reasons, I didn't say anything back then, but woah!!

[+Stephen]

Odd - only uses around 1-2% CPU on my box (AMD Phenom X4-955).

[Mclaneinc]

Using around 5 - 9% on my P4 3.2g, any known load heavy items I can try on it for WCS?

[Faicuai]

It pulls about 18%-20% of avg. CPU usage on my dual-core HDMI (Nvidia) Dell Studio and by loading one core about 50% more than the other. All this with Artifacting TURNED OFF. This laptop runs Win7-64, in dual-screen virtual desktop (quasi 720p on its screen, and 1080p on the primary screen) and it is certainly tuned for emulator-usage (it eventually ends with a 42-process list, 18%-19% of memory usage (530MB of overall ram usage), and a 0% CPU (or fractionals below 1%) usage after fully booting, running all of Windows service/maintenance stuff, and unloading all possible Win-bloatware from RAM, except antivirus which STAYS ON permanently. As an example, MAME-UI64 (which I use extensively) chews-up 12% to 25% in most Z80-emulations, all pretty evenly distributed across both cores.

Altirra is using about 35% of the CPU time on my machine, but it's this difference in auto-repeat speed which really has me bugged. KEYREP is set at 5 in PAL mode and 6 in NTSC mode (as one might expect), but while keys appear to repeat a roughly 10 per second in NTSC mode, the repeat is noticably slower in PAL mode.

 

 

...I've just fired-up my highly-tuned HDMI Dell Studio 1440z (my main machine), and tested Altirra v2.0-T3. Key auto-repeat sound-playback works nicely and fluid (all my setup is NTSC, though), Chopfliter-Atari-US ROM intro's music-playback runs nicely and fluid (no hiccups), Zaxxon scrolling seems acceptably fluid in Windows mode, and, when hitting ALT+ENTER and going in full-screen mode, it is buttery / pixel-fine smooth (same with PolePosition). These last two scrolling-samples are pretty messy (jittery and broken) in Atari800Win+ 4.0, for instance.

 

I will have to try the AxelF-tune demo, but, so far, it works just nice in my tuned-machine, with 13% to 18% total reported CPU usage (I see it permanently on the Studio's screen, while having Altirra active on in full-creen mode on the HDMI output). This usage is pretty much in-line with the normal usage I see in MameUI-64 emulating one (1) main CPU (e.g. Z80) in combination with one (1) custom sound chip, for instance.

 

On top of that, I can now see all those H-Scrolling artifacts and visual bugs on the right-side that I can see from high-quality A-to-D captures from my real machines.

 

Everything seems fine-and-dandy, so far.

 

F.

Edited May 27, 2011 by Faicuai

[phaeron]

A few comments:

• Altirra is indeed a relatively slow Atari emulator, and I don't expect that to change. That isn't because I wouldn't want it to be faster, but because of the requirements of cycle-level emulation. The main big offender is the ANTIC/CPU interleave, which is needed to emulate cycle-exact playfield DMA timing, but another one that I've been meaning to address is POKEY. The POKEY emulation is event based, but the problem is that sometimes POKEY is left with channels spinning at high speed (AUDFx = $00), leading to the odd behavior that the emulator runs faster when music is being played. I need to split off the non-program-visible events so I can dispatch and optimize them separately.
  
• Unfortunately, 2.00-test is a little bit slower than 1.9. The reason is the extra overhead to support virtual playfield DMA (the right border scrolling artifact).
  
• If you are getting sound breakups, increase the audio latency in System > Audio Options. I'm not surprised that this would happen if you've got a desktop recording application running.
  
• Regarding the key repeat rate, the speed may vary if you are in the default cooked key mode. The reason is that in this mode, the host OS is the one doing the auto repeat, and the Atari OS can't accept keystrokes as fast as it does autorepeat due to software debounce. You should see more consistent behavior in raw key mode.
  
• Vertical sync mode can make the reported frame rate less stable, since it has to delay or advance frames to match the display rate. The average will still be correct, but the Atari's frame rate deviates slightly from standard rates and the issue is worse if your display is running at a rate like 40Hz or 75Hz. Full-screen mode is smoother because there Altirra uses flipping instead of timed blits.
  

[Keatah]

Odd - only uses around 1-2% CPU on my box (AMD Phenom X4-955).

 

Not odd at all, the more powerful the host processor the less percentage is used. For the same amount of work that is.

[Keatah]

Using around 5 - 9% on my P4 3.2g, any known load heavy items I can try on it for WCS?

 

I would guess that since Altirra strives to be cycle exact, regardless of what you run through it, the host cpu usage will change little, if any.

 

I ran StarRaiders, Acid800 test, Atari 8-bit Boink(the amiga ball), BallBlazer, MEMO PAD. And everything stayed around 27% usage. Graphic intensive or not, processor intensive or not. Average is 27%. Those pokey and antic and gtia and 6502 chips are constantly running. And they don't vary their clock rate. If they did, well then, your host cpu usage would vary also.

 

Having the remains of two exploded Zylons dissipating seems to take as much host CPU time as an idle memopad. Altirra should use X amount of host CPU time to get you Xfps. I see little correlation between emulated load and host processor load.

 

Changing HOW Altirra uses your system resources WILL affect your host CPU load. Full screen shows an increase in host CPU usage. If you do warp speed to get more cycles from the emulated circuitry, then yes, your host CPU usages will go up. Sure. Some disk access might cost you a percentage point here or there. Changing sound sampling rate would also affect host usage.

 

Changing NTSC artifacting or FrameBlending, yes, that would make host usage go up too.

 

But back to the Star Raiders thingy, the original 400/800 would experience a slowdown you could see, and hear, when you blew up too many raiders at once. Even the photons would slow down. Now. Altirra emulates that exact same slowdown. For the circuitry is buzzing along at 1.79MHz (for sake of argument)! It ain't speed'n up or bogg'n down.

 

If you made it run at 3.5Mhz, yep, you'd see host usage climb.. If you made Star Raiders adjust the speed of the emulated cpu to handle the extra 3-d calculations for the exploding ships, then you'd see an increase. Yeh, SR uses real 3-d math to compute the moving starfield! How kewl is that?

Edited May 27, 2011 by Keatah

[flashjazzcat]

• Regarding the key repeat rate, the speed may vary if you are in the default cooked key mode. The reason is that in this mode, the host OS is the one doing the auto repeat, and the Atari OS can't accept keystrokes as fast as it does autorepeat due to software debounce. You should see more consistent behavior in raw key mode.

That never occured to me. Thanks for clearing that up. I'm almost completely happy now.

[Mclaneinc]

Don't worry, when I see slowdown in games I realise from experience of the real machine that its not the emulator being slow but it actually mimicking the real machine as it should, too many other emulator users have been spoilt / pleasured by the unticking of the sprite limit checkbox or fake CPU speeds. Whilst its nice to see smooth play I also like 'correctness' and emulation accuracy know that there's no false additions that will spoil the program from running correctly ie floating point calc's etc.

[Keatah]

Don't worry, when I see slowdown in games I realise from experience of the real machine that its not the emulator being slow but it actually mimicking the real machine as it should, too many other emulator users have been spoilt / pleasured by the unticking of the sprite limit checkbox or fake CPU speeds. Whilst its nice to see smooth play I also like 'correctness' and emulation accuracy know that there's no false additions that will spoil the program from running correctly ie floating point calc's etc.

 

I would often take advantage of the slowdown in Star Raiders to look at the Galactic Chart or LRS. Or perhaps reconfigure my ship quickly.

[Keatah]

Going back to the correct Star Raiders colors, this post in this thread -- http://www.atariage.com/forums/topic/182394-variation-in-screen-color-for-8-bit-star-raiders/page__view__findpost__p__2288674 -- has a screenshot showing exactly how it should be. I remember this precise color scheme from when my parents had their home theatre system calibrated and adjusted. We also had a new out of the box 800 that happened to be adjusted just right.

 

This screenshot from real hardware gets everything right!

A800XL-sVideo-FRAME-SRaiders-2.bmp

 

NOW! NOW!

With Altirra, I can get the almost exact same color palette by changing sliders in the Adjust Color box. Starting with the Authentic NTSC scheme, you need to set the HUE STEP to 24.7 and SATURATION to 18% !! This seeming works well on my shitbox laptop. I have no doubt that it will also work on my professional panel and the home tv set as well. The values might be a little different depending on the type of LCD panel you have and what angle you view it at.

Edited May 27, 2011 by Keatah

[atx4us]

• Regarding the key repeat rate, the speed may vary if you are in the default cooked key mode. The reason is that in this mode, the host OS is the one doing the auto repeat, and the Atari OS can't accept keystrokes as fast as it does autorepeat due to software debounce. You should see more consistent behavior in raw key mode.

That never occured to me. Thanks for clearing that up. I'm almost completely happy now.

 

Have you had a chance to try the raw key mode yet? It works for a few autorepeat keystrokes and then freezes for me.

[flashjazzcat]

Have you had a chance to try the raw key mode yet? It works for a few autorepeat keystrokes and then freezes for me.

Yeah - just tried it. Seemed to work fine until I fired up The Last Word, and then held keys wouldn't repeat at all.

[Mclaneinc]

Have you had a chance to try the raw key mode yet? It works for a few autorepeat keystrokes and then freezes for me.

Yeah - just tried it. Seemed to work fine until I fired up The Last Word, and then held keys wouldn't repeat at all.

 

Just tried it, used cooked keys and it produced a weird 'after effect' where a held down key seemed to have a double sized buffer when let go and kept on going for a bit.

 

Swapped to raw keys and all worked as expected, tried LW and holding down a key produced the right effect and stopped once let go..

 

(2.00 beta3 used)

[Faicuai]

Here's Altirra (v1.9 or v2.0-T3) on StarRaiders, color-adjusted for proper NTSC color-signal display, as close to my 800XL-sVideo as it can be.

 

Looks glorious on my Sony Bravia KDL-52W3000, via Dell Studio 1440z-HDMI.

 

Attached images.

 

F.

Edited May 28, 2011 by Faicuai

[Keatah]

Here's Altirra (v1.9 or v2.0-T3) on StarRaiders, color-adjusted for proper NTSC color-signal display, as close to my 800XL-sVideo as it can be.

 

Looks glorious on my Sony Bravia KDL-52W3000, via Dell Studio 1440z-HDMI.

 

Attached images.

 

F.

 

Looks very nice! I have prepared 3 color profiles for Altirra ((hey Phaeron, why not make a user palette #1, #2, #3, #4 save slots?)) by using the registry. What I do is just export the color section of the Altirra registry entry. And by clicking on the resulting .reg file I can change the profile to fit the moment.

 

Sometimes I use my shitbox laptop LCD, othertimes I hook the shitbox up to my theater. And if I go out visiting, I have yet 2 more display options. And the lab has some nice graphic arts LCDs which also need their own set of color adjustments.

 

All the commentary in this thread and in -- http://www.atariage.com/forums/topic/182394-variation-in-screen-color-for-8-bit-star-raiders/page__st__25 -- have been completely invaluable in helping me get correct colors going for my favorite 8-bit games, especially, SR.

Edited May 28, 2011 by Keatah

[Mclaneinc]

Just an Update from Phaerons blog..

 

http://www.virtualdub.org/beta/Altirra-2.00-test5.zip

http://www.virtualdub.org/beta/Altirra-2.00-test5-src.zip

 

This version adds speed control, a debug display in the debugger, and fixes for failures in the ASAP 3.0.0 tests. The speed control has known issues right now with causing sound breakups at slower than normal speeds. One of the ASAP tests, cpu_ane, will still fail because I'm not sure the test is valid: it fails on my real Ataris, too.

 

I'll get around to tweaking the colors again at some point, once I have time to sit down and figure out a happy average. Gamma correction is a bit annoying: it's easy to do on a palette, but slower to do in the RGB modes (PAL artifacting, NTSC high artifacting). That's the main reason I haven't done it.

 

I've bypassed Phaerons beta 4 release as beta 5 is a bug fix for it, just incase the sharp eyed people spotted the jump.

[Keatah]

After enjoying correct star raiders colors by tweaking the palette, I noticed that it seemed like a 1-time thing. So to speak. With Star Raiders working right, I tried out Rescue on Fractalus, and BallBlazer. The ground in ROF is too green, and the sky not yellow-orange enough. But just a tiny bit. And the grid in BallBlazer is washed out, with a hint of violet and green. But, damn! Star Raiders is perfect.

 

With Atari 800 Emulator 2.1.0, the colors are correct for all 3 games, with no tweaking, not that you can adjust the palette in that emu in the first place.

 

Sure, adjusting colors can be a personal thing. And one of us might see slightly different shades of a color - to make things more fun! What I do, is I look at a bunch of other sources and compare them against what should be. Whether it be photography (professional for many many years) or astronomy, or video game emulation.

 

I read through the blog on your homepage, and I'm not so sure I've seen a solution that would fix this yet.

And I only "complain" in hopes of getting this to be the absolute best emu possible!

Edited June 2, 2011 by Keatah

[Faicuai]

After enjoying correct star raiders colors by tweaking the palette, I noticed that it seemed like a 1-time thing. So to speak. With Star Raiders working right, I tried out Rescue on Fractalus, and BallBlazer. The ground in ROF is too green, and the sky not yellow-orange enough. But just a tiny bit. And the grid in BallBlazer is washed out, with a hint of violet and green. But, damn! Star Raiders is perfect.

 

With Atari 800 Emulator 2.1.0, the colors are correct for all 3 games, with no tweaking, not that you can adjust the palette in that emu in the first place.

 

Sure, adjusting colors can be a personal thing. And one of us might see slightly different shades of a color - to make things more fun! What I do, is I look at a bunch of other sources and compare them against what should be. Whether it be photography (professional for many many years) or astronomy, or video game emulation.

 

I read through the blog on your homepage, and I'm not so sure I've seen a solution that would fix this yet.

And I only "complain" in hopes of getting this to be the absolute best emu possible!

 

Compared with MANY games ran at 800XL+high-quality A-to-D video conversion, and then with Altirra (including Fractalus), and then evaluated in my Bravia 52" screen. The result is almost flawless, in pretty much all games.

 

In your case, slide HueStart from -57 to -51 (do not touch ANYTHING else) and find the best balance of primaries (Red, Greens & Blues you can get). You will need to factor in for your screen's output, etc.

 

Atari800 Emulator 2.1.0 *DOES NOT* has the right colors (or at least the colors that my calibrated HW reproduce), *guaranteed*. The 800XL naturally pulls to the green-side in some key areas, while the JayMiner-800 is a bit more reddish, which eventually I prefer, but I am sticking to the emulation "golden rule", here.

 

Cheers,

 

F.

Edited June 2, 2011 by Faicuai

[Keatah]

In your case, slide HueStart from -57 to -51 (do not touch ANYTHING else) and find the best balance of primaries (Red, Greens & Blues you can get). You will need to factor in for your screen's output, etc.

 

Atari800 Emulator 2.1.0 *DOES NOT* has the right colors (or at least the colors that my calibrated HW reproduce), *guaranteed*. The 800XL naturally pulls to the green-side in some key areas, while the JayMiner-800 is a bit more reddish, which eventually I prefer, but I am sticking to the emulation "golden rule", here.

 

Cheers,

 

F.

 

Well thanks for that! I've gotten somewhat closer and a seemingly very good compromise all around.

I set the HueStart at -51

I never figured setting up colors could be so tedious! I'll try this out later on downstairs on the big screen and see what it looks like. I also have an old "professional" Sony GDM 520 21" CRT which was calibrated with the adobe colorspace in mind, I believe. It could be interesting to try. But for me it's all LCD all the time.

[Kr0tki]

In your case, slide HueStart from -57 to -51 (do not touch ANYTHING else) and find the best balance of primaries (Red, Greens & Blues you can get). You will need to factor in for your screen's output, etc.

Faicuai, if I understand correctly, the -57 setting corresponds to output of your 800XL, while -51 matches your 800, right?

 

Your 800 is an interesting case - it is so far the only known unit which produces "hue 1" that is not equal to the colorburst. I'd like to investigate this discrepancy further, so I'm asking - could you send a screenshot of your 800 displaying the palette? (Or have you posted it already?) There's a slight chance that I discover the reason of the discrepancy just by analysing the screenshot.

 

Atari800 Emulator 2.1.0 *DOES NOT* has the right colors (or at least the colors that my calibrated HW reproduce), *guaranteed*.

Note that Keatah speaks about version 2.2.1. Erm, nevermind.

 

Keatah, why don't you upgrade to Atari800 2.2.1? The 2.1.0 has its colour emulation rather broken, believe it or not.

Edited June 2, 2011 by Kr0tki

[Keatah]

Haha.. I *JUST* found the new version 2.2.1 and spent some time absolutely enjoying the kick-ass NTSC artifacting.

[Faicuai]

 

Well thanks for that! I've gotten somewhat closer and a seemingly very good compromise all around.

I set the HueStart at -51

I never figured setting up colors could be so tedious! I'll try this out later on downstairs on the big screen and see what it looks like. I also have an old "professional" Sony GDM 520 21" CRT which was calibrated with the adobe colorspace in mind, I believe. It could be interesting to try. But for me it's all LCD all the time.

 

 

No probs.

 

You WILL NOT be able to dial-in a "recipe" value, but rather play whithin a specific window of such values (particularly HueStart, once HueStep is anchored around 25.1 or so). Find/dial-in the value that gives you the overall best compromise/look you remember OR (preferably) what YOUR real HW looks on YOUR evaluation screen.

 

Note: *DO NOT USE* an AdobeRGB-calibrate screen, as NTSC-colors are going to show MUCH more saturated... or you are willing to compensate for Saturation in Altirra's Saturation Control.

 

 

Cheers,

 

F.