Altirra 2.70 released

[Keatah]

Does Tools> Options> Startup> "Reuse Program Instance" make a difference?

[fujidude]

Doh.... I had VBXE disabled in the U1MB. My brain is fried. Is that a new(ish) option in the new FJC BIOS? My mind is blank on it.

[AtariGeezer]

Does Tools> Options> Startup> "Reuse Program Instance" make a difference?s

Nope, but I just tried version 2.5 test 40 and it ran 10 times without an issue.

2.6 test 3 works good too, 2.6 test 41 crashes...

Edited April 10, 2016 by AtariGeezer

[phaeron]

@phaeron,

 

If you default to DirectX 11, will that cause a problem with us DX9 users?

 

Not unless you are running under Windows Vista or later and your graphics card wigs out only in the D3D11 path. Windows XP systems won't be affected at all as they don't have DirectX 11 and the emulator will just fall back to DirectX 9. The emulator already supports this if all options are checked; the fallback order is D3D11 -> OpenGL -> D3D9 -> DirectDraw -> GDI.

 

I just realized I might have to restrict the default to Direct3D 11.2 (Windows 8.1), because the main reason to default to D3D11 is for improved vsync. Windowed mode vsync kinda sucks with D3D10-11.1.

 

Did I mention how much of a pain modern display APIs are? It's much easier when you can hook the VBI interrupt and swap a display list pointer....

 

Nope, but I just tried version 2.5 test 40 and it ran 10 times without an issue.

2.6 test 3 works good too, 2.6 test 41 crashes...

 

I uploaded a super-archive containing all 2.60 test releases (20MB):

http://virtualdub.org/beta/Altirra-2.60-test5-to-test40.7z

 

Could you narrow down the last build that works for you? I don't see anything suspicious in the changelogs -- there were no real display changes between 2.50 and 2.60. The only thing that stands out is that I did switch the compiler mode for the 64-bit build from v120 to v120_xp to support XP64 and I really hope that didn't do anything.

[flashjazzcat]

Doh.... I had VBXE disabled in the U1MB. My brain is fried. Is that a new(ish) option in the new FJC BIOS? My mind is blank on it.

Been there since Candle's BIOS.

[AtariGeezer]

I uploaded a super-archive containing all 2.60 test releases (20MB):

http://virtualdub.org/beta/Altirra-2.60-test5-to-test40.7z

 

Could you narrow down the last build that works for you? I don't see anything suspicious in the changelogs -- there were no real display changes between 2.50 and 2.60. The only thing that stands out is that I did switch the compiler mode for the 64-bit build from v120 to v120_xp to support XP64 and I really hope that didn't do anything.

You bet, it's 3:53am now and will check them out this afternoon...

[tschak909]

 

 

Did I mention how much of a pain modern display APIs are? It's much easier when you can hook the VBI interrupt and swap a display list pointer....

 

Hear hear! Although, I am glad that certain things are being set into motion on other platforms (e.g. Linux with Wayland), where the display pipeline is being significantly shortened, and the display system rigidly enforces frame synchronization.

 

-Thom

[AtariGeezer]

Could you narrow down the last build that works for you? I don't see anything suspicious in the changelogs -- there were no real display changes between 2.50 and 2.60. The only thing that stands out is that I did switch the compiler mode for the 64-bit build from v120 to v120_xp to support XP64 and I really hope that didn't do anything.

Okay, found it.

 

Altirra-2.60-test6 - Works good, even after exiting Altirra-2.60-test7 from a fresh boot.

Altirra-2.60-test7 - Works from a fresh boot (like the current release), but trying to run again after exiting results in the reboot.

 

Looking at the notes, only thing that was changed was more BlackBox support...

 

 

Edited April 10, 2016 by AtariGeezer

[phaeron]

Great... yeah, nothing else significant in between those two besides switching the compiler for the entire code base to Visual Studio 2013.

 

Can you try the following:

• Launch Altirra with /gdi to disable Direct3D mode.
• Switch the display filter mode in the View menu from Sharp Bilinear to Bilinear.
• Close Altirra.
• Restart Altirra without /gdi.
• Check Options > Display and ensure that Direct3D 9 mode is enabled.
• Close and restart.

There was one other change to add support to Sharp Bilinear mode for older graphics cards. It should not affect your card because you have a shader model 3 capable graphics card, but we'll see.

[AtariGeezer]

Okay, I tried the above on the current version and Altirra-2.60-test7 with the same results.

After "Restart Altirra without /gdi." both version cause the reboot.

Did the "Check Options > Display and ensure that Direct3D 9 mode is enabled" too after the PC came back up, no difference.

 

Then I tried resetting all settings to default, went through the setup wizard, re-started Altirra and the crash still happened...

[mr-atari]

Hi Phaeron,

 

I found a small issue with MyIDE-][ emulation.

Presentation of the status-bits 7,6,5 in register $D50E are incorrect when the card is pulled. (e.g. remove harddisk in devices).

After removal the real hardware locks into "wait for reset" state, removing all bits.

Altirra does not remove bit 6 & 5 I see.

 

So with card and powered-up the bits are 111x.xxxx

Remove card should be 000x.xxxx, altirra does 011x.xxxx

x are undefined bits and float most of the time.

 

I was testing the hotswap-support and came across some weird behavior, this explains it :-)

 

Grtz,

Sijmen.

[phaeron]

Thanks to help from AtariGeezer, found what was causing his rebooting problem. It was a combination of a regression in the way that VS2013 writes manifests in executables and an old, nasty bug in Windows XP Service Pack 2. I've released 2.71 with a workaround, but for those of you still on XP -- either install Service Pack 3 or the KB921337 hotfix.

 

And, as for the devline:

 

http://www.virtualdub.org/beta/Altirra-2.80-test30.zip

http://www.virtualdub.org/beta/Altirra-2.80-test30-src.zip

• Includes manifest workaround from 2.71.
• Fix for MyIDE-II CF status behavior with card removed.
• Fixed power-up values of the PENH and PENV registers. (I had the bright idea of writing $FF into LPENV and waiting for it to change to detect when OS stage 2 VBI had run. That didn't work.)
• Retuned sector read timings based on actual 1050 measurements. In particular, command ACKs arrive sooner now.

[AtariGeezer]

Thank you Phaeron for helping me with this :thumbsup:

[Atari_Ace]

Hi phaeron,

 

I was trying out the various text modes with Altirra OS/BASIC and noticed issues when switching between them.

• In standard video, if you expand the window the text window expands either horizontally/vertically or both depending on the current size ratios.
• In enhanced text hardware intercept, it stays fixed size, and shifts offscreen if you make the window too small.
• In enhanced text CIO intercept, it expands to the full window ignoring the current ratio the moment you resize the window. If you don't resize, it stays in the last ratio.
• If you switch from CIO to hardware when the CIO mode is stretched out to a large window, the window doesn't resize, but carriage return starts to expose BLACK regions eventually showing the window is the upper left quadrant only. If you resize it snaps to the center again.
• If you switch from hardware to CIO when the window is large, you start with a small window. If you went from standard to CIO it would fill the window immediately.

I think it would be helpful to redraw when the mode changes always to avoid some of these artifacts. Also, it would be nice if the hardware intercept stretched the screen like the standard mode, but that is probably intentional.

 

[Kyle22]

I would suspect some of the text mode differences are normal because of raster fonts vs truetype.

[phaeron]

Sort of, not quite. The enhanced text modes render text 1:1 on screen, so the font size you pick is the font size you get. This avoids stretching the rendered text, which produces poor quality text. Text can't be stretched trivially because of font hinting, which changes the pixel size of characters at smaller sizes -- you can avoid this by disabling hinting, but that produces blurry text (like in Internet Explorer, and current release versions of Edge).

 

The size of the CIO intercept mode not being correct on switch I can fix. The hardware intercept mode is a bit trickier as it currently doesn't try to change the height of the rendered screen, which always has 30 rows (the max possible).

[doctor_x]

So is Altirra pretty much the only emulator worth using these days? I'm going to get back into things here shortly and am trying to decide on the emulator to use....

 

Thanks!

[+Stephen]

So is Altirra pretty much the only emulator worth using these days? I'm going to get back into things here shortly and am trying to decide on the emulator to use....

 

Thanks!

Yes. Altirra is the only one to consider - actively being developed, by far the most accurate, debugging tools integrate with modern dev tools like you wouldn't believe, etc.

 

P.S.

SDX fits this category also. This is brought to you by the one and only, "my opinion is the only correct one", Mopar Stephen.

[Keatah]

So is Altirra pretty much the only emulator worth using these days? I'm going to get back into things here shortly and am trying to decide on the emulator to use....

 

Thanks!

 

Pretty much. For reasons too numerous to list.

 

Atari800 Emulator 3.1.0 has better NTSC effects, but that is just one single point where it pulls ahead.

[Mclaneinc]

Win Plus is pretty much dead in the water so its a choice of 3, Atari++, A800 and Altirra, Atari++ is nice but I can't stand the GUI, so clunky. A800 is very good indeed, maintained well but again its a clunky interface so for me its Altirra all the way. It features just about anything you could want on the Atari and a lot more, the support from Avery is excellent and its as close to the real thing as is possible (for me).

 

If you want compatibility, adaptability and ease of use then Altirra is for you but do have a look at the other two as its horses for courses, what I don't like in a GUI others may love.

 

@Keatah, what do you mean about the NTSC effects please, just interested..

[doctor_x]

thanks guys!

[Keatah]

I find the NTSC filter settings to be a little more versatile and they produce a more CRT-like image. A little more RF-like. Atari800 Emulator 3.1.0 uses the Blargg filter package which is also used in the Stella VCS emulator.

 

Things like colorburst phase, edge fringing/bleeding, and resolution can be adjusted. Also the intensity of the scanlines can be changed. I like scanlines, but not the full on or full off setting.

 

The image also can also be stretched to cover 100% of a 4:3 monitor. With Altirra I get a few 10 or 15 pixels boarders on the left/right parts of the image.

 

Perhaps it is just a personal preference..

Edited April 18, 2016 by Keatah

[doctor_x]

I have used a few emulators before but it has been several years... I tried Altirra out this evening and maybe its just because I havent seen any of the competitions recent releases but Good Lord Altirra looks and runs AMAZING... The emus I remember were so very clunky and slow... This thing is almost a work of art and the screen looks awesome on my giant PC monitor.... Definitely going to get a controller and play a few games - but even more it seems like with some learning I could even get stuff like BBS Software to run via emu...

 

Fun times ahead!!! Thank you for the awesome work. I will definitely be contributing...

[Keatah]

Indeed it is a work of art. All the major 8-bit rigs in one box and rather customizable too. The UI, while it does NOT look progressive and phabletty and Metro'ish, it is crazy functional and works da'bomb.

 

I personally dislike emulators that have their own built-in "Atari'ish-looking" menus. WTF are they thinking? Are they trying to hide boring Windows conventions and drop-downs? Erm, helloooo, knock, knock! There's no need for all that, and it's confusing & fatiguing too.

 

For a wow moment this evening, try out BallBlazer at 7 or 10 MHz..

System -=> CPU Options -=> [x] 65C816 (7.14MHz)

 

Isn't that scrolling nice or what?

 

[morelenmir]

So is Altirra pretty much the only emulator worth using these days? I'm going to get back into things here shortly and am trying to decide on the emulator to use....

 

Thanks!

 

In addition to what the other chaps have outlined, I would add that Altirra tends to scale depending on your requirements as well which none of the other emulators do in my opinion. What I mean is that if you 'just' want a virtual Atari to play the old games on - fantastic, Altirra will do that. If you want to get in to writing assembler for the A8 - Altirra is the best debugger available, to the extent you can just think of it as an extension to Eclipse/WUDSN. Do you want something to test new firmwares or your own customizations of them on before writing to real hardware and perhaps bricking the system? If so then once again Altirra is your tool of choice - or should be. To be honest I probably use it for that last purpose more than anything else theses days; for instance putting together a new SDX customization with drivers and tools in the userarea is must less stressful if you test it first in an imaginary A8 before you try writing to the SIDE2!!! In fact there is no other way to do this if you are using real hardware which does not have a memory expansion. Again, you can almost think of Altirra as dedicated tool just for that purpose.

 

All in all Altirra is the definitive A8 emulator. Moreover, while it does have failings they are being actively worked on and Phaeron will usually take requests - even quite esoteric ones so long as they are not too time-consuming to implement.

 

The only significant areas which you might found your needs not met are perhaps in the emulation of some peripherals like say the 'Happy' or Indus disk drives, the SIO2SD and so on. Again though this is not really a failing as such- simply Phaeron only has so many hours in the day and to implement cycle-perfect simulations of these devices would not only be time-consuming but might well slow the emulator itself to a crawl on even powerful PC hardware. If these types of things are important to you - which I totally understand as they were to me at one point in the past - then you have a perfect reason to get in to real retro hardware as well!!!