[5] faust # AtariAge Altirra 4.20 | !!! Piątek, 15 Grudnia 2023 23:08 CET [15-12-2023 22:58 CET]
![[ATARI] Altirra x86 i x64 4.20 test XXX 14/12/2023](www/picphoto/19a443df1.jpg)
Nowe wersja testowa Altirry emulatora ATARI XE/XL/5200/2600.
Ostatnia pełna wersja tego emulatora, autorstwa Avery 'Phaeron' Lee, jaka publicznie została udostępniona to Alirra 4.10 z 1 stycznia 2023 r.
Przy okazji, nie wiem czy ktokolwiek zdaje sobie sprawę, że Altirra ma już prawie 15 lat deweloperki za sobą - ale ten czas leci.
changes:
features added:
bugs fixes:
author's comment:
changes
features added:
bugs fixes:
author's comment:
changes:
features added:
bugs fixes:
author's comment:
changes:
features added:
bugs fixes:
author's comment:
changes:
features added:
bugs fixes:
author's comment:
This is a bit of a grab bag, so going down the list in more detail:
The UIAutomation code now supports text formatting attributes, so it can report foreground/background colors. Interestingly, NVDA seems somewhat better at naming colors than Windows Narrator, as Narrator will report "teal" and "maroon" for colors that NVDA reports more accurately as "blue" and "red".
The 835 modem emulation is based on the 1030 emulation, with adjustments for the 835 hardware. It requires the 835 firmware as there is currently no high-level emulation; the 835 hardware and firmware are so close to the 1030 that this was a relatively quick adjustment. Unlike the 1030, the 835 has no boot support and no tone dialing support, but interestingly it does support playing phone audio, which the 1030 doesn't. So the 835 shipped with phone audio but no tone dialing, the 1030 shipped with tone dialing and autobooting but no phone audio, and then finally the XM301 had both phone audio and tone dialing but no autobooting. As far as I can tell the 835 doesn't seem to have shipped with a T: handler at all, so pretty much the only thing that officially could drive it was TeleLink II.
The Performance Analyzer can now import a monitor trace generated by Atari800WinPLus 4.0's TRON/TROFF commands, which is essentially a big text file with one line per instruction. This requires some hokey tricks to re-assemble the instructions back to opcodes and guessing at a bunch of missing information, but it's enough to get some usable traces. For instance, the importer reconstructs an approximation of SIO traffic based on POKEY register accesses, so here's a trace of the SuperDOS 5.1 issue in Atari800WinPLus, where SuperDOS tries to do a high-speed Status command and A8WP responds with Error instead of NAK:
The importer does have to fill in quite a bit of missing information. There is no indirect effective address (EA) information, no halted/unhalted cycle accounting, and it has to guess when interrupts occur and what type. The serial traffic timing is approximated since the trace only shows when the CPU read SERIN or wrote SEROUT, and not when the shifters actually ran. The instruction trace can also have the wrong opcodes for some undocumented instructions, since the importer actually has to run an assembler to recover the opcodes. But it actually works better than I thought it would.
Note that Altirra's binary trace format is more compact than this text format. The raw TRON trace above, which is just under 4 seconds, generated a 116MB raw text file. It compresses to 5.9MB with .zip and 1.1MB with .7z, but is 349K when resaved to .attrace format. Text trace with instruction logging is of course easy to implement, but it doesn't scale too well to four minute long traces.
As for why the importer only supports output from the older Atari800WinPLus 4.0, it's just because newer versions of Atari800 don't seem to have the monitor trace functionality compiled into the official Windows releases -- they're built with the TRACE command disabled.
changes:
features added:
bugs fixes:
author's comment:
changes:
features added:
bugs fixes:
author's comment:
Probably not surprising after I posted the dumps for the 1030 chips -- I had propped the firmware on a munged version of the XF551 emulation to confirm some things, and it wasn't too hard to get the full modem working from there. A couple of things are currently missing: analog loopback, and the relay sound. The 1030 has an audible 'twing' from a small relay when it puts the phone on-hook, which is most noticeable when pulse dialing and more characteristic than the default short thud that Altirra plays.
changes:
features added:
bugs fixes:
author's comment:
changes:
features added:
bugs fixes:
author's comment:
changes:
features added:
bugs fixes:
author's comment:
changes:
features added:
bugs fixes:
author's comment:
Something a little different -- this build adds some basic accessibility support:
changes:
features added:
bugs fixes:
author's comment:
The story behind the RUN "C" change: there are some BASIC tape loaders that are protected with a zero-length immediate line. This caused a lock-up when the emulator tried to boot the tape with CLOAD followed by RUN, because the RUN statement would lock up the interpreter. Problem is, RUN "C" doesn't work on other tapes because it uses long IRGs instead of short IRGs, and there's no CRUN command. So what Altirra does now is that it uploads a small patch to temporarily shim the C: device so that RUN "C" uses short IRGs and both kinds of tapes work.
changes:
features added:
bugs fixes:
author's comment:
The PerfAnalyzer .attrace format contains most of the same data as the in-memory trace, but with better compression and a more version-independent format. CPU instructions, hardware channels, and video frames are saved; tape trace channels are not currently supported. The existing in-memory CPU trace format compresses the raw history from 28 bytes/instruction down to ~8.5 bytes/instruction, while the serialized format uses a combination of Deflate and more aggressive encoding and blocking to get this down as low as ~1.2 bytes/instruction. The result is that a 2min. PAL trace takes about 70MB on disk, and a full 12min. trace of the Numen demo is ~600MB. The encoding/decoding process is fairly involved and the trace needs a bunch of memory to unpack, so the 64-bit version is highly recommended if trying out this feature as you may run out of memory with the 32-bit version.
The .attrace format itself is not yet documented, though I plan to once it's more finalized and the reader is more flexible. The top-level container is a .zip file, though the majority of the data is binary encoded. The CPU trace format is designed with a flexible predictor system, so it's possible to encode traces without the full set of predictors that Altirra uses -- which means mostly just dumping register state per instruction into a fixed-size record stream.
changes:
features added:
bugs fixes:
author's comment:
The exported debug help produces an HTML page (debughelp-4.20-test17-t2e.pl.html) that is inspired by some ones that others have generated; it works by dumping the dbghelp.txt into an HTML template and parsing with JavaScript. I wanted to just drop in the dbghelp.txt file raw, but needed to escape characters since HTML doesn't support CDATA. You can, however, easily substitute in an escaped version of dbghelp.txt from any other version. An example is attached.
changes:
features added:
bugs fixes:
author's comment:
changes:
features added:
bugs fixes:
author's comment:
changes:
features added:
bugs fixes:
author's comment:
changes:
features added:
bugs fixes:
author's comment:
changes:
features added:
bugs fixes:
author's comment:
If you're suspicious at this point of the specific devices added here, you're correct, this is for MIDImaze:
A lot of this was work to write a new generalized socket service in the emulator to make it easier to implement network connected devices. Which means that there are now four socket worker classes in the emulator, but the plan is to get that eventually down to one to end the madness.
For two nodes, the MidiMate device needs to have a networked serial port device attached, with one listening on a TCP port while the other connects to it. The connecting side will keep trying to reconnect every few seconds.
For three or more nodes, the computers need to be linked in a loop from MIDI in to MIDI out line per the MIDImaze directions. This requires using the network splitter so the input and output directions use separate TCP connections. Input doesn't need to be listen and output doesn't need to be connect, but each connection between nodes needs connect on one side and listen on the other.
A limitation of the current setup is that anything that pauses the emulator will cause the game to drop, because the emulation being paused will prevent MIDImaze from communicating and the game times out after a fraction of a second.
As for MIDImaze's multiplayer protocol itself, it appears to be lockstep with transferring input, so its data transfer requirements are minimal (as would be needed at 300 baud).
changes
features added
bugs fixed
author's comment:
There is a known issue where attempting to run CPS SuperSALT with the test assembly in 800 mode will result in one test failure on POKEY from the I/O test. This is due to some weird behavior in the test that I can't figure out. The issue is that the test assembly hardwires controller ports 1 and 3 together and one of the joystick lines to joystick 1 trigger input, and it sets PORTB to output mode pulling all lines up while checking the joystick trigger, which is pulled up when it expects it to be low. This gets flagged as paddle A input stuck at +5V since the test assembly also hardwires paddle A input to the same joystick line, but the code in question is special-cased to test only trigger 0 and flag just that one paddle line. The other strange thing is that this part of the test code also leaves the SIO command line floating as an input when it is normally used as an output to enable the ADC output on the joystick lines, but that should be getting pulled up on the computer side.
changes
features added
bugs fixed
author's comment:
changes
features added
bugs fixed
author's comment:
changes
features added
bugs fixed
author's comment:
The 1400XL and 1030 do tone dialing by coupling the Atari's audio output to the phone line and then play the DTMF tones with 4-bit volume only audio through POKEY. It's not the highest quality, but it is good enough. The tricky part is that this meant that the emulator couldn't tell if or what was being tone dialed without doing DTMF detection on the audio, Altirra now has both pulse and tone dialing detectors and can actually tell what number is being dialed, although that information isn't used yet -- it still just "dials" the dial proxy address.
The DTMF detector was a bit involved, it required downsampling to 8KHz and running a filter bank to compare the power in the DTMF tones versus the rest of the signal. The compiler did a bit of a crappy job in code generation for the filter, but it's still <1% CPU.
changes
features added
bugs fixed
author's comment:
Revision F or newer 1450XLD handler firmware is now required for the TONG controller, as the rev. E handler will get stuck on the non-installed D2-D4:.
With this update, the two-sided mode of the original controller will now work, as documented in the Intro to DOS 3 manual -- D1: and D2: will now refer to the first and second sides. The TONG controller does not implement this, as instead it supports DSDD operation. However, the DSDD layout is not compatible with the XF551 on side 2, as it allocates tracks forward with sectors backward, instead of both tracks and sectors backward.
The TONG controller will now also boot double density, but there is a significant odd incompatibility that the emulator papers over. For some reason, it stores the boot sectors in the last half of the sector instead of the first half. The result is that if you try to boot a disk that has been formatted with another double-density drive like the US Doubler, the TONG controller won't be able to boot it properly. The emulator remaps the boot sectors on a decoded format like ATR to the layout that the 1450XLD expects so double density can actually be used, but it can still fail if you use a format like ATX that can actually store the full physical boot sectors.
I did some tests with the 1450XLD controller and different interleaves, and it is indeed fast -- in single density, it can keep up with a 2:1 interleave. Double density is a bit slower and needs more like a 3:1 or 4:1, but is still faster than many SIO-based disk drives even with high-speed operation and track buffering. It's doubtful that it could have kept up with a 1:1 interleave even with rewritten controller firmware, though -- the timing for this would have been too tight without track buffering due to the separate read/transfer stages.
As for the V:/T: handler firmware versions, they are virtually the same, with CRC32 5EC3EC7D being the slightly newer firmware. The T: handler has a fix for an IRQ reentrancy issue in the interrupt handler, while the V: handler has a fix for an additional character encoding (not sure about the details yet).
changes
features added
bugs fixed
author's comment:
First thing to say about 1400XL/1450XLD: voice and telecomm does not work currently. The handlers will initialize, but V: does not actually play any voice and T: cannot actually dial out. I tried hooking up V: to the system speech API, but that is not amenable to just-in-time phoneme delivery. T: requires more research into the 1400XL's audio circuits as there are some unusual control bits that affect the audio routing. There is one new handler ROM for the V: and T: devices that are automatically added in 1400XL mode.
The 1400XL OS is not needed to use the 1400XL/1450XLD. The 1400XL is essentially just an 800XL with memory mapped at $D600-D7FF and two built-in PBI devices (V:/T:), and the regular XL/XE OS is perfectly capable of driving all of the new devices; despite some of the 1400XL OS revisions having reference to separate internal device PBI registers, the known handler ROMs are designed to work with standard $D1FF access. The 1400XL OS is rather underwhelming. The initial version has almost no real differences from the XL/XE version 2 OS that it is chronologically closest to, but is incompatible with a lot of software because of small changes that shift almost all of the routines in the $Cxxx region by 2-6 bytes, and an SIO change that also shifts some of the routines in the main EF region. The silliest changes are due to the OS having been reassembled by a newer assembler that fixed some instructions being unnecessarily assembled with absolute addressing mode instead of zero page when accessing page zero locations, e.g. STA CRITIC changing from 8D 42 00 -> 85 42. Reverting back to the rev. 2 OS for the remaining products was very much the right move.
The parallel disk controller is more interesting. In order to use it, you need to manually add the 1450XLD controller device, of which there are three versions: standard 1450XLD with real handler but simulated controller, 1450XLD with real handler and real controller (full emulation), and 1450XLD "TONG" with real handler and real controller (full emulation). The PBI handler ROMs are cross-compatible but the TONG and non-TONG controller ROMs are not, the TONG firmware will not work on the non-TONG hardware or vice-versa. Furthermore, the TONG controller firmware that was posted on the Atari History Museum site is NOT compatible with the TONG schematic that was posted with it; I had to reverse engineer the changes to the circuits from the 8048 disassembly. When the 1450XLD device is active, the parallel disk controller will take over D1:. It also tries to shift the SIO drives, which will not currently work as in the emulator they will fight over the D1: disk interface.
The design of the parallel disk controller is odd. It is essentially the SIO protocol redirected over a PBI interface, with regular command frames and data frames. This includes a bit of silliness like the SIO checksums still being computed and sent. The daughterboard version of the disk controller is quite underwhelming -- despite having a double-density controller and 256 bytes of RAM, it only implements single and enhanced density and the basic 1050 command set. The data transfer protocol is slow for a parallel interface due to handshaking, but it's still a bit faster than SIO divisor 0. The sad part is that despite the disk controller being fast enough to read at least 5:1 high-speed interleaved disks, it doesn't support formatting with a high-speed skew. Since the controller also doesn't have enough memory to do track buffering, this means that in most cases it is no faster than a 1050. Also strange is that despite the 1050 being well-established when this was made, the density reporting is incompatible, with medium density being reported in bit 5 instead of bit 7. The PBI handler ROM is pretty buggy, with the earliest Revision E handler [CRC32 E8F9C8A7] being the one that boots most reliably with the commonly available 1450XLD controller. It will actually boot many copy protected disks, but compatibility is hindered by the handler not returning sector data on a read error. Holding the SELECT button on start tells the handler to slow down disk reads to closer to 810/1050 timing, if you happen to have a faster interleaved disk.
The "TONG" controller is more evolved. Despite the TONG schematic showing a compatible circuit to the daughterboard, the controller ROM that's been published for it does not work on it -- it requires different chip select bits for the FDC and RAM. The controller firmware is quite a bit improved, with support for double-sided double density, 1050-compatible density reporting, fixed density detection, sector number validation, faster format, faster transfers, and more reliable ATTN/BUSY protocol handling. Of the three handler ROMs that work with it, the "U6" ROM [CRC32 29359910] appears to be the latest. However, I haven't been able to get the controller to boot double density. There is, unfortunately, a major bug in the TONG controller that wasn't in the earlier version: it always returns the current type I FDC status from the Get Status command instead of the FDC status from the last read, which alone breaks the majority of protected disks. It also still doesn't support a high-speed skew format, which is a shame given a disk interface that could out-do any SIO high-speed disk drive.
The 1450XLD controller shares similarities with the XF551, which is also 8048 based. It actually has a faster CPU (10MHz vs. 8.3MHz) and more RAM (256b internal + 256b external vs. just 256b internal), and runs at 288 RPM instead of 300 RPM. However, the XF551 was definitely more polished, supporting the PERCOM block commands, being more compatible, and being much more tightly coded. The two also have incompatible DSDD formats. Both write to side 2 with reversed tracks, but the XF551 also reverses the sector order.
changes
features added
bugs fixed
author's comment:
The PowerPad controller is an interesting controller. It is natively a multi-touch controller, which poses challenges for emulating it with standard input methods. Micro Illustrator is particularly unusable without it as it requires a minimum of two touches to use, one to set the current position and another to activate. To support this, the emulator supports pre-setting a secondary touch and activating it via a second button. With the default mouse-mapped input map, this is done by setting the contact point and radius with the middle mouse button and then activating it with the right mouse button. With the default gamepad mapping, up to four multitouch points are supported, with those points changed when pressing the appropriate button with left trigger (LT) held. Right trigger (RT) is mapped the same as the primary touch button for convenience.
The timing of PowerPad reads is currently untuned and currently instant, as I have no information as to how long the matrix scans actually take. The delays that appear are in the software, to avoid running afoul of the impedance-related signal limits on the controller port. A quirk of the PowerPad is that reading the pad slows down as the contact areas grow bigger, since it takes longer for the scan to return every individual contact switch to the computer. Every point is currently returned to the computer, as there isn't a mention in the docs of point filtering/coalescing. This means that in Micro Illustrator, drawing will be more responsive as the touch point is shrunk (mouse wheel). The default radius is about a finger width.
There are a few additional changes that I'm considering that haven't made it in yet. One is altering the default pad area to be square and configurable. Currently it is always mapped to the window, which is often non-square -- thus the contact oval that you will see right now until the window is adjusted. Combined with the previous changes to allow the display to be arbitrarily positioned, this would allow for more natural arrangement of the pad area vs. the display. The other change is support for actual multi-touch input for those with touch screens. Altirra currently has multi-touch support, but it isn't plumbed all the way through to be usable for PowerPad emulation yet.
changes
features added
bugs fixed
author's comment:
changes
features added
bugs fixed
author's comment:
Display pan/zoom lets you pan and zoom the display to any desired placement. It's independent of the existing sizing settings, but lets you manually offset the screen or zoom in very close on a selected part. It can be accessed either from View > View Frame > Pan/Zoom Tool, or by Alt+MMB drag for pan and Alt+Wheel for zoom. The direct controls are on Alt to prevent accidental zoom, especially with a trackpad.
changes
features added
bugs fixed
author's comment:
changes
features added
bugs fixed
author's comment:
![[Atari] AtariOnLine: ATASCII Compo - 4. edycja](Photos/www/photo/201611/atari-atarionline-logotyp.gif,134)
[Atari] AtariOnLine: ATASCII Compo - 4. edycja
![[VCS] Stella 7.0 4/10/2024](https://www.t2e.pl/Photos//www/photo/202011/atari-vcs-stella.png,134)
[VCS] Stella 7.0 4/10/2024
[Atari] AtariOnLine: Gra "Dangerous City" uwolniona!
![[VCS] Gopher 0.35.0 2/10/2024](https://www.t2e.pl/Photos//www/photo/202410/atari_2600-gopher-.jpg,134)
[VCS] Gopher 0.35.0 2/10/2024
![[Atari.Area] Czwarta edycja ATASCII Compo!](https://www.t2e.pl/Photos/www/picClean/atari2134.jpg,134)
[Atari.Area] Czwarta edycja ATASCII Compo!
http://www.virtualdub.org/altirra.html
I had access to a number of 8-bit computers in my childhood, but my most favorite was the Atari 800, a 1.79MHz 6502-based computer with color graphics and a disk drive, and which as the predecessor to the Amiga, another favorite of mine. Over a decade later, I was struck by both nostalgia and ambition and started to write a new 8-bit Atari emulator from scratch. This is the result.
At this point, I've learned a lot more about the Atari and Altirra now emulates more than I ever had or did years ago, but I still work on it periodically. It also serves as a modularity test for the VirtualDub code base, from which Altirra shares some components. If you are struck by nostalgia too or have a desire to do some Atari development, perhaps it might be useful to you, too.
https://forums.atariage.com/topic/345943-altirra-410-released/
© Try2emu 1999 - 2024 | Krzysztof 'Faust' Karkosza Kontakt Polityka Prywatności OWU
