GoodByteXL

At least for using Altirra under a linux gui it is quite easy. With Linux Mint I created after installation of WINE a symlink: sudo ln -s /usr/share/doc/wine/examples/wine.desktop /usr/share/applications/ Could be possible linux will need a restart, depends ... Thereafter right-click on the respective Altirra EXE and you will be prompted with an option to open this exe with the WINE Windows Program Starter. Click and go ... No Windows hassles anymore. In my view this is the only real disadvantage of Altirra. I cross my fingers it will be generally usable under WINE in the future.

OTP EPROM's are an option. I use it for projects when it is clear it won't be changed.

As it was not mentioned: Did you check the setting of CADJ ?

LESS in SDX.

off topic This is something I tried to confirm for all the decades since the 80's. And the result to me: it is nonsense to blame the capacitors, as long as they are fine. I never (!!!) had and have the need to extract the SIO caps in more than 40 machines over the decades to get reliable SIO highspeed. And I had a lot of discussions about it over the decades. To my experience a clean SIO signal has absolutely no problem to function as Atari produced it. To proof this I repaired an old 800 XL mainboard, Rev C, last winter and tested it. NO issues! Next I extracted ALL CAPS C71 to C78. No difference. A friend of mine checked that using a logic analyzer and told me that there is a very small cleanup effect by doing this, but nothing spectacular. This is why PD 0 is no issue on the side of the Atari machine itself. The signal might get disturbed by other devices and then deteriorates - in this case it might help. The only instance I know is concerning the XE machines. The original Atari schematics for the 130 XE floating around do show an important error. C71-78 are doubled in those drawings: 1 set guided directly to the POKEY, another set close to the SIO port. I saw XE mainboards carrying both cap sets. These machines might have problems to get higher speeds than PD 4. The caps close to the SIO port are superfluous, if the ones around POKEY are on the board. Of course there are so many other issues having an effect on the SIO lines, that every user might get a different experience and coincidentally does something that heals the problem. Then with the next re-arrangement of the setting the game might start over again.

Good catch. Indeed do not use those trailing path delimiters in my batches. Will for the time being put a note in the manual with the PCL driver.

No - there is simply no need for it as SDX uses unlike Atari type DOS relative file access. Jumping to any sector anywhere on the drive is blazing fast compared to Atari type DOS. And, if you expanded a directory by copying too many files to it, approx. more than 200, it will never decrease. Empty it and delete it. To cleanup there is a tool for it on the tool kit.

Given you are using real hardware, there are a few things to keep in mind ... If there is a hardware cache inside your machine, it might not work with the PCL driver. Disable it (like I recommended that in the manual for the FIFO). SIO high speed might be too high (here I cannot use the PCL driver at higher settings than PD 4 with PCL). Starting with PD 3 and lower creates that experience you described then. Of course this is related to my hardware. It might be different over there. If possible, please use the latest version of SDX -> 4.49g and the corresponding tool kit. Used RespeQt 5.3 (test-wise, standard version is 4.0 here) under Linux to recursively do copies to and from a PCL drive; works fine here. I do my backups also that way. To speed the process up a little bit you could use COPY /RS switching off ANTIC.

RTFM ... Driver - yes

Took some time to find it, but here is the oldest hint to this problem I know of: ANALOG issue 45, page 23, Using BASIC XL's Hidden Memory by Robert Opitz

Yes, all ABBUC e. V. content from 1985 - 2015 is covered on this DVD:

Besides using it under Linux - Are there any printers working at all? Tried it lately and it is a mess. The only readable output is on 1020 as long as it does not comprise more than 1 page. Every next page gets printed on the first sheet. Redirection to a PDF under Linux works fine, but again, everything on 1 page.

Dug it up, finally. This is what Simius proposed and I followed it:

Yes and no - the problem arose back then when trying to engage bank $D5 for other uses, e. g. internal real time clocks. So it has not necessarily to be a 'stacked cart' but something using that bank. When resigning the those carts this fix should always be taken into account.

I came across the same experience you described years ago. I wanted to use CF and SD cards with Rev C as I did before with the MSC IDE Controller. Simius told me that there is a kind of incompatibility of Rev C with 'some' CF adapters for IDE. As a fix he sent me some guidelines how to modify the Rev C - and it works fine since then with adapters and still with hard drives. My standard setup uses a 4 GiB CF card using a large FAT partition as an read-only archive. The CF card is frequently mirrored to an image to be used with Altirra running the same setup in hardware. As for another run it it still save to use IDE 2.5 as there are more than sufficient options to use adapters for it. Even if IDE to M-SATA seems to be a crazy idea, such an adapter plus a small SSD is relatively cheap compared to an an CF adapter and brand CF card.