Altirra 2.70 released

[Atari Nut]

Update:

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

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

 

Fixes some odd behavior with overlapping SIO commands and has a bunch of fixes and improvements to the custom shader support:

• Fixed some parsing bugs.
• Precompiled shaders are now used by default if present.
• Shaders can be precompiled with option shader_precompile=true.
• Shader profile can be forced above 2.0 with shader_profile_d3d9=2_0, 2_a, 2_b, or 3_0.
• Profiling is now supported (shader_profiling=true)
• Includes are now supported when compiling.
• FP16/FP32 framebuffers are now supported.
• Border texture addressing is now used when available.
• Added shader validation.

Attached is a port of a TV shader that you can try. I didn't write it; a link to the original source is in the archive. I removed a couple of components that didn't work well, especially the flicker. Just a warning, it's not that well optimized -- it requires shader model 3.0 and runs at about 7ms/frame on my Quadro K2100. This means that even if you do get it to run you may run into frame rate or vsync problems depending on how fast your graphics card is. However, it looks pretty neat. Unfortunately, running .cg shaders verbatim is not going to be possible since there is simply too great of a difference between Cg and HLSL and the shaders often have a lot of constructs that are not valid in the ps_3_0 profile, even if not actually used.

 

 

This is unfortunately due to how the CPU core and memory breakpoint systems work in the emulator. On a real 6502 or 65816, indexed store instructions always do a possibly false read followed by a true write. The reason is that the CPU needs an additional cycle to process a carry on a page crossing, and while indexed loads are optimized by doing a speculative read without doing the carry to try to save a cycle, writes can't be done speculatively. This means that for indexed stores the CPU always does a dummy read cycle at a possibly incorrect address before doing the write at the correct address. Altirra emulates this in the CPU core because there are cases where this matters, particularly if the dummy read hits a hardware register that is read sensitive (PIA data register, IDE data register, cartridge banking registers). The problem is that access breakpoints are implemented as a memory layer in the memory subsystem and thus it too sees these false reads. In turn, the way the CPU core works, it doesn't know whether this read is a false read until the next cycle where it computes the carry. The result is that read breakpoints will frequently trigger on indexed writes. It is also possible to get false reads from branches since the CPU will also do a false instruction read in that case. It's all accurate to the real hardware behavior, but not frequently useful.

 

I've been trying to think of ways to fix this and allow the CPU core to identify false reads for the breakpoint system, but haven't figured out a good way to do so without slowing down the CPU emulation. In the meantime, the only good workaround is to use conditional breakpoints to filter the read breakpoints so they don't trip on the problematic instructions, i.e.: bx "read=(address) and db(pc) != $91". It's annoying, but it's better than nothing.

 

The 65816 core has the same issues, but it's a bit more problematic there because the 65816 explicitly signals when it is doing internal operation (IO) cycles, making it easier for the motherboard to ignore those cycles and avoid unnecessary wait states. I haven't worried about this much because the 65816 mode doesn't attempt to be cycle-exact to anything physical, but it'd be more of an issue if I did (like, say, Rapidus).

 

 

The help file is out of date -- I only recently added the second audio monitor in stereo mode. But yes, as you've discovered, when SlightSID emulation is enabled it replaces the standard POKEY monitor.

 

 

I wasn't able to reproduce the issue with PCLink, but I did run into some odd behavior with the PBI BIOS's high speed driver enabled that may have given a clue. Give the above build a shot. The issue has to do with what happens when the computer tries to send a command while the device is still busy with a previous one. The common behavior is that the device ignores the second command, and a less common behavior is that it interrupts the first command to process the second. The emulator's SIO manager was doing some unholy mix of the two, which may have resulted in some garbled command responses.

 

Older versions of the emulator required you to pick whether the SIO routine was interrupt-based or polling-based as it had two separate strategies for doing burst I/O. I figured out how to combine the two, so current versions only have a single option. As usual, the documentation is out of date.

 

The VintageTV shader is cool. Is there a way to round the corners with this?

[Mclaneinc]

In a word, no...

 

BUT as long as the shader you use meets the normal standards laid out in shaders then a similar one from say BSNES etc should work, obviously the corner rounding is down to the shader itself.

[_The Doctor__]

rounded? at that rate go for circular :0 lol

I always went for the clearest squarest tube I could find ...

 

some tv's and monitors were pretty bad though...

scan lines and dot pitch mattered as well.

 

scan lines really do help though

Edited December 26, 2018 by _The Doctor__

[Atari Nut]

Back then, I always had sets with rounded corners. I prefer it looking like I remember it. I can do it with MAME and HLSL but sadly, the Atari emulation is not very good.

[Kyle22]

I had an RCA NuVista Color with a round tube. 21" IIRC. It had a front plate masking the top and bottom so they were flat, but the sides were round. It was a big heavy floor model from the early 60's.

It had a beautiful picture (after I tweaked the convergence controls. [i am extremely anal about convergence. It MUST be perfect])

 

That Nuvistor tube in the tuner made it extremely sensitive. It would pick up channels far away even with a bad antenna.

 

Wikipedia Nuvistor: https://en.wikipedia.org/wiki/Nuvistor

 

Atari looked good on it, but the corners were a problem with some things.

 

Edit: Added picture.

 

Nuvistor is about 11mm diameter and 20mm high, not much bigger than a discrete transistor, but more sensitive and can handle higher frequencies.

 

Edited December 27, 2018 by Kyle22

[Mclaneinc]

Back then, I always had sets with rounded corners. I prefer it looking like I remember it. I can do it with MAME and HLSL but sadly, the Atari emulation is not very good.

 

 

Have you tried other shaders in Altirra?

 

Ignore that, I just tried loads and no joy, loads of parsing errors or expecting odd and sods here and there..

 

I personally don't use them, about as radical as I go are Bilinear and scanlines with the built in artifacting TV look..(which I love as its how I remember my old BUSH or was it Sony little TV)

 

Sorry I can't help...

Edited December 27, 2018 by Mclaneinc

[flashjazzcat]

You could always place the monitor inside this:

 

[Mclaneinc]

A little cruel, yes....Funny, also yes...And of course it does actually work

 

What we need now is a pack of plastic bezels that sit in front of the screen

 

One with a crack on it, one with a dead fly, maybe some blurred in some parts...

 

All excellent instant retro feels

Edited December 27, 2018 by Mclaneinc

[Atari Nut]

 

 

Have you tried other shaders in Altirra?

 

Ignore that, I just tried loads and no joy, loads of parsing errors or expecting odd and sods here and there..

 

I personally don't use them, about as radical as I go are Bilinear and scanlines with the built in artifacting TV look..(which I love as its how I remember my old BUSH or was it Sony little TV)

 

Sorry I can't help...

 

Yea...I also get the same parsing errors with the other shaders. I do like the look of Bilinear, Scanlines and Artifacting and that's what I will continue to use. I just wish there was cubic distortion for that convex appearance and round corner.