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.

It is like written earlier ... Or in other words, the OSS supercart does not allow the usage of bank $D5xx as it kills what is there unless corrected.

Yep, took it from the corresponding article I wrote for ABBUC magazine #105. It reads like this:

When modifying the original OSS pcb it needs an additional 74LS32 if you plan to use the rest of the bank $D5 together with one of the OSS languages in M091 cart format. I am not familiar with the boards from PCBway. BITD I managed to modify one of my OSS carts to a 4-in-1 type hosting ACTION!, BASIC XL, BASIC XE, and MAC/65. More than a decade ago I learned with the help of Hias that those carts lack proper decoding and modified my OSS-4-in-1 again.

Please keep in mind that the original cart design M091 does lack a proper address decoding. While banking the whole bank $D5 is addressed, what causes other hardware or software using other parts of that bank (than the few addresses really needed by these OSS carts) to crash. For correct schematics please contact tfhh in this forum. It needs one more chip - LS 32 - to solve this. Or a proper programmed GAL, etc.

Reading always helps and one might detect not only how to use the X command but also the COMEXE.SYS to help out automatically. Programs known to be in need of the X command carrying the extender EXE will then be started the right way. Please see also the remark with MENU in chapter 4.47.1 as it behaves a bit different here. And nearly forgotten to mention: It is described in the chapters 2.15, 2.16, and 2.17 being part of the 'Introduction To SDX' how to handle programs.

Second that as it performs correctly here with SDX 4.49g and BASIC XE 4.1 and the corresponding Extensions. It is an additional aspect to be watched here: The extensions stay in memory as long as the A8 is not shut down. So doing a cold boot won't kill it.

You should - please read chapter 8.3 in the user guide to see what can be achieved. For most users there is not really a need to change anything in the CONFIG.SYS on the CAR device. Nearly everything can be managed by a .SYS in the subdirectory SPARTA.DOS on the boot medium. It offers up to 19 choices to be placed there for a customized CONFIG.SYS. Besides, the driver is already noted in the CONFIG.SYS on SIDE3. See attached screenshot.

confirmed for IDE+, SuperCart, and SDX128Cart

If you cannot get to grips with it, please note that SpartaDOS X is capable of reading MyDOS subdirectories. This way one can retrieve the data and save it to another non-MyDOS medium for future usage. If SDX is not available on your A8, Altirra comes in handy.

Please see the extended driver for it available on the SpartaDOS X Toolkit.