Nowe wersja testowa Altirry, emulatora ATARI XE/XL/5200.
Ostatnia pełna wersja tego emulatora, jaka publicznie została udostępniona to Alirra 3.90 z 14 czerwca 2020 r.
[1] faust # AtariAge Altirra 4.00 | Czwartek, 10 Września 2020 23:01CET
Nowe wersja testowa Altirry, emulatora ATARI XE/XL/5200.
Ostatnia pełna wersja tego emulatora, jaka publicznie została udostępniona to Alirra 3.90 z 14 czerwca 2020 r.
changes
features added
bugs fixed
authors comment:
changes
features added
bugs fixed
authors comment:
This release also contains the source code for the RMT plugins.
changes
features added
bugs fixed
authors comment:
changes
features added
bugs fixed
authors comment:
changes
features added
bugs fixed
authors comment:
changes
features added
bugs fixed
authors comment:
Regarding the two-tone audio issue -- I tested timer 1+2 two-tone timing against the actual hardware and 3.90+ is correct, with 3.20 being off by two cycles. The actual issue was a corner case in where a resync 1+2 tones signal on the same cycle where an underflow happens causes the output pulse to be suppressed, which wasn't happening and resulting in a pure tone instead of a complex tone. This case wasn't being hit in 3.20 for the pitches involved due to the two cycle difference in period.
As this is the first test release after the addition of the Check for Updates feature, it'll be interesting to see how well it works. The feed won't be updated until about 10 minutes after this post lands, since I have to update the feed with the link to this post.
changes
features added
bugs fixed
authors comment:
Also in this version is the main thing I've been working on, the ability to check for updates online. This is only a manual check for now as I haven't added the logic to auto-check on startup, but Help > Check for Updates will now fetch an update feed to check if there is a newer release (test or stable, depending on which type of build you are running). Quite a lot was involved here including signing certificates (yuck) and the Windows CryptAPI/CNG/WinINet APIs (double yuck), but hopefully once it's all working smoothing it'll be a more convenient way for people to find out about updates. Note that the update mechanism only shows when a new build is available, it doesn't download or install it.
The underlying notification mechanism uses a subset of RSS 2.0. I haven't decided how widely to publicize this, but you can subscribe to it in a regular feed reader:
https://www.virtualdub.org/feeds/altirra-update-dev.xml
Note that there is a chicken-and-egg problem in that for the test releases, the link in the update feed is the AtariAge post announcing the new release. This means that you'll always hear about it here first, because I can't get the link for the feed update until the post has been made!
changes
features added
bugs fixed
authors comment:
The Tape Editor now has the ability to view and edit the turbo decoder side of the tape, as well as to show the waveform input to the decoder (if waveform caching is enabled on load, which is off by default). For the turbo signal, this shows the post-filter output. The analysis tool now also has rudimentary Turbo 2000 decoding capabilities:
You can also see the distortion in the source waveform due to high frequency attenuation, which is what the compensating HPF is for:
changes
features added
bugs fixed
authors comment:
Tape editor has also received a few upgrades. It now has commands to convert selected ranges between standard (decoded bytes) and raw FSK, and also to extract files stored in standard C: format.
It also has two analysis features. The first is an Analyze tool that, when dragged over a selection, decodes and displays bytes in that selection. The second is an option to capture bytes as decoded dynamically through POKEY. Together, these can be used to diagnose boot errors:
In this case, the problem is a poorly encoded CAS file containing a transition from a standard 'data' block (green) to an 'fsk ' block (blue). The gap in between (gray) is of the wrong polarity, causing a framing error from the start bit being shortened (red byte).
We can fix this by using the Draw tool to repair the start bit:
...only to run into a problem later in the tape:
Here the analyzer is able to successfully decode the block with a valid checksum (blue bytes), but the boot fails with a framing error. The cause is a slight difference in estimated baud rate that causes the analyzer to just barely squeak by, whereas the OS boot is just slightly off enough for the stop bit sampling position to spill over into the next start bit (gray ticks). This is caused by another data/fsk split within the block, which causes timing problems since 'data' blocks can only specify baud rates to the nearest integer:
...but since the analyzer can decode the block, we can have it rewrite the entire block as clean standard data to avoid the mid-block change in baud rate and the marginal bit sampling timing:
...and now that the tape boots properly, resave a repaired .cas file.
changes
features added
bugs fixed
authors comment:
changes
features added
bugs fixed
authors comment:
changes
features added
bugs fixed
authors comment:
changes
features added
bugs fixed
authors comment:
changes
features added
bugs fixed
authors comment:
changes
features added
bugs fixed
authors comment:
changes
features added
bugs fixed
authors comment:
changes
features added
bugs fixed
authors comment:
HDR support makes it possible for the emulator to display NTSC colors that would otherwise be clamped and altered in sRGB, especially on displays that can handle wider color spaces. To enable it, you need an HDR-capable display and graphics card, Windows 10 1709+ with HDR enabled in Settings, and DirectX 11 and accelerated screen effects need to be enabled in the emulator. If everything is set up correctly, the HDR options will become available in View > Screen Effects and you will be able to enable HDR and just the SDR/HDR intensities. This is best done with a colormap so you can see the effect on the color palette -- you want the HDR white intensity to be set below the max brightness of your display to provide headroom for saturated colors. Highly saturated hot pink colors in particular reproduce much more accurately with HDR mode enabled -- if you compare the NTSC Contemporary (XL) profile in SDR and HDR, the $2F/3F/4F colors and artifacted purples are closer to a TV or CRT monitor. You don't need a great monitor to do this, even a garbage-tier HDR monitor at 350 nits can still work.
There was some significant rework in the display paths and there are a couple of combinations of display settings that occasionally give a washed out gray screen from the wrong color range being used, either on-screen or in copy/record; I'll be fixing these up before release once I find a better way of testing all of the different combinations. When things are working correctly you will still get an SDR image from the copy image or record commands since the clipboard and Media Foundation don't really support HDR yet. (Which is kind of annoying, as there isn't a reasonable way for me to post of picture of what it looks like.)
For those who don't have an HDR-capable setup, there are a couple of other options. A display capable of Adobe RGB will do fairly well if you switch both the monitor and emulator to that color space, since Adobe RGB is wider than sRGB and closer to NTSC in gamut. (DCI-P3, which is increasingly popular, is somewhere in between and I don't have a monitor supporting it to test against.) Alternatively, you can reduce Intensity Scale down to around 70% and boost the brightness of the display. The downside of these methods is that it will distort the display for everything else. I've experimented with automatically implementing psuedo-HDR this way, but it's complicated by inconsistent ways of changing the display brightness, including DDC/CI for monitors and IOCTL or WMI (ugh) for laptop displays.
changes
features added
bugs fixed
authors comment:
The work on the display code was prompted by a new monitor that I got that supports HDR/WCG and adaptive sync. HDR on Windows 10 is, frankly, a total mess -- the way it is integrated into the system is non-sensical, with it having to be enabled system-wide to use it at all. It would have some benefit in the emulator in being able to boost brightness higher than the desktop and encode to wider gamuts like DCI-P3, but there is some really bad compression going on at scRGB >1 on my system that makes it unusable since I can't tell what the transfer curve is. I could probably fix this in full-screen mode by bypassing to the NVIDIA or AMD APIs to enable HDR and outputting HDR10 directly, but that's too much work right now.
Adaptive sync / FreeSync / G-SYNC does mostly work, but there are still some gotchas. The primary benefit is that it allows the monitor to actually run at 49.86Hz or twice that for smooth PAL video. You will need to disable Vertical Sync in the emulator for this to work. On my system, it only works through DisplayPort and not HDMI, and can sometimes fail to activate when multiple monitors are active. For D3D9 it only works in full-screen mode; in D3D11 it will work windowed and borderless fullscreen as well as long as windowed mode G-SYNC is enabled in NVIDIA settings. When enabled correctly, it largely eliminates the PAL juddering.
changes
features added
bugs fixed
authors comment:
changes
features added
bugs fixed
authors comment:
changes
features added
bugs fixed
authors comment:
changes
features added
bugs fixed
authors comment:
changes
features added
bugs fixed
authors comment:
changes
features added
bugs fixed
authors comment:
changes
features added
bugs fixed
authors comment:
changes
features added
bugs fixed
authors comment:
© Try2emu 1999 - 2024 | Krzysztof 'Faust' Karkosza Kontakt Polityka Prywatności OWU