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.
[0] faust # AtariAge Altirra 4.00 | !!! środa, 16 Września 2020 22:18 CET [16-09-2020 22:07 CET]
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:
For those who don't know, the Atari 815 is an odd duck. It has two drive mechanisms and is the only Atari 8-bit disk drive I know of that has no floppy drive controller chip. Instead, Atari opted to brute force it with a 2MHz 6507 (faster than the computer!), 4K of ROM, three 6532 RIOT chips (mislabeled as PIAs), a MC6852 Synchronous Serial Data Adapter (a.k.a. overgrown shift register), and a data separator made out of miscellaneous logic. It is also the only disk drive that cannot read a single density disk, with its hardware and firmware limited to MFM. It also cannot read enhanced density -- the hardware is capable of doing so, but we'll give the designers a pass for not supporting a format that didn't exist yet. The 815 does support code upload, and a couple of the extra commands are suspiciously similar to ones in the 810 revision E firmware, which implies a relationship between the two. No support for high-speed, sadly, even with the 4K ROM and 2MHz CPU -- and with hardware support for another 2K ROM expansion this drive could have done a lot. As the 815 has no FDC, the firmware itself reads and writes raw MFM data, including scanning for sector headers. The emulator has to synthesize a raw MFM track to support this and without the FDC doesn't know what sectors the firmware is trying to access, so currently the emulation is read-only and only shows track numbers instead of sector numbers. The hardware strips MFM clock bits on read but requires the firmware to encode to MFM and calculate CRC-16s in software. It's surprisingly capable of doing this with the 2MHz CPU and the drive formats with a 16:1 interleave, slightly faster than US Doubler standard interleave. The one sub-par thing I've found is sync -- instead of just waiting for the $4489 pattern to appear, the 815 has to use a two-step process to detect the $44 and then check the $89. This means that it will miss the sync when a pattern like $44489 shows up and makes the drive unusually dependent upon the $00 bytes before the sync. The drive also doesn't report errors the same way as an FDC, although this is hard for me to test as ATX doesn't support double density disks yet and there aren't really any copy protected double density disks anyway.
The 815 seems to be format compatible with other double density drives, including the three boot sector convention -- which is interesting, considering when this drive was made (1980-1981?). It's also the only drive to implement the mysterious Read Spin, Motor On, and Verify Sector commands documented in the Atari Operating System Manual that no other drive implements.
You'll need the 4K firmware to make this work, combining the two 2K ROM images. I've opted for a format where the A107 chip is first and the A106 chip is second, which matches the canonical order in the address space ($0800-17FF). For convenience, it is attached. All copies of the 815 firmware that I have found, including those from Bob Woolley, are the same, with A107 CRC32 32BD3CFD, A106 CRC32 C13657E0, combined CRC32 1527D542. Some dumps come with an extra 6-byte Atari executable header that must be removed.
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