Thanks a lot for the detailed info and the pictures!
It looks like your 65XEs has 1nF caps on the SIO lines, if the schematics I have here are correct C77 and C78 (looking like resistors) should be the one's on data in/out - if in doubt check with a continuity tester. It'd be good to remove them (desoldering the end connected to SIO or just clipping this side off is fine).
Concerning baud rates: POKEY has a bit quirk in receive mode, it doesn't sample in the middle of a bit but it's skewed by about 7 clock cycles. This means for the highest baudrate the transmit baudrate has to be a tad lower otherwise it won't work. So for NTSC Ataris using the calcualted PAL baud rates is already sufficient, but for PAL Ataris it needs to be set still a bit lower. This is why I don't use the NTSC frequency in my calculations but base everything on PAL frequency.
In my tests this worked quite fine (both on NTSC and PAL systems) and there's some upper and lower headroom we can operate in. It's all a bit tricky as UARTs usually can't operate at any given baud rate but will round it up or down to the next closest supported baud rate.
So knowing that 109800 worked for you is really helpful information! It could well be that I need to manually tweak the fastest baudrates up again a bit.
Concerning the command line: having that connected (and enabled in atariserver) will help atariserver detect command frames more reliably, especially if you have other SIO devices connected to the SIO chain. With just the RPi / atariserver connected the "no command line" mode seems to work rather well though (actually better than I had expected). If you like you can give it a try, copy over the dtbo files from contrib/rpi to /boot/overlays and enable the uart-ctsrts dtoverlay to get CTS on GPIO pin 36 (see README.rpi for details).
If pokey divisors 1 and 0 aren't working check if there are really no caps on the SIO data lines in your XE. I'm not too familiar with all variations of the XE line, some seem to have them soldered on board, some directly to the SIO connector.
What kind of level shifter did you use and did you add a diode and pull-up resistor in the SIO data in path? If you have the diode you could try removing it (directly connect the level shifter to SIO data in), this won't allow other devices on the SIO chain to be used but helps with capacitive load on the SIO bus as data-in will be driven by a push-pull driver (instead of the open-drain driver you get from the diode).
Another thing you could try is adjusting the baud rates. When you choose a pokey divisor you'll get the baud rate used printed in atariserver's log window. You can manually select a (slightly) different baudrate by appending it to the divisor, separated by a comma - eg "0,125000" - this works both on the command line with the -S option and in the curses interface ("S" key). Test with 500 and 1000 baud above and below the nominal baudrate.
I recently lowered the baud rates for the highest pokey divisors a bit (eg from 125000 to about 124000 on divisor 0) as Lotharek's USB SIO2PC had issues with that. The currently used baudrates worked fine though in all of my tests (also tested on RPi3 with both PAL and NTSC 800XLs).
Automatically downshifting the baudrate / divisor won't work. The highspeed SIO implementations on the Atari query the drive for it's speed on the very first access and then stick to that (some implementation, like mine, do an auto-fallback to standard speed in case of errors).
Atariserver doesn't show the currently used baudrate, but you can manually enable additional logging by setting UTRACE_MASK in tools/UserspaceSIOWrapper.cpp - setting it to 0x08 will notify you about baudrate changes. Better disable this additional logging for normal use though as it can screw up the timing.
I had another quick go at it and implemented another bootable version (hisioboot-atarisio.atr) that'll automatically swap D1: and D2: via the AtariSIO remote control interface. This means you can simply put hisioboot-atarisio.atr in D1: and the ATR you want to boot in D2: and it'll automatically switch to it and continue booting that after the OS has been patched. Note that this'll only work with AtariSIO/atariserver, for other SIO emulators you'll have to adapt the code (hipatch.src is the main file, atarisio.src contains the code to swap drives on atariserver).
Concerning the RPi: make sure you use the full UART (/dev/ttyAMA0), not the mini UART (/dev/ttyS0) - the latter won't work well. On a RPi3 just use the "pi3-disable-bt" or "pi3-miniuart-bt" dtoverlay.
The easiest way to trigger another boot is to end the boot code with "SEC, RTS" instead of "CLC, RTS". A set carry flag means boot failed, the OS prints a "BOOT ERROR" message and then does another boot attempt.
I had a quick go at it and created a bootable ATR with the highspeed SIO patch (see attachment).
Concerning AtariSIO: you don't need the kernel module on the Raspberry Pi (it'll only work on a PC with 16550/16950 UARTs), just use atariserver/atarixfer with the /dev/ttyAMA0 serial port (similar to how you use sio2bsd).
The US Doubler really is a beast. Not only does it not set the percom block, it also doesn't set bit 7 of the first byte in the get status result if an enhanced density disk is inserted, like the 1050 or Happy do. At least it sets bit 5 of the status byte in case of a double density disk :-)
So the only reliable way to distinguish between single and enhanced density seems to be to check if a sector > 720 is readable. I've now implemented that in atarixfer (checking for sector 1040) and testing with my Mega Speedy in US Doubler mode worked fine.
I can't comment on ALibPC but as I added support for Lotharek's dual SIO2PC/1050-2-PC USB interface a couple of months ago my guess is ALibPC probably needs some changes.
By default Lotharek's dual interface works in SIO2PC mode with command on CTS, so can work with pretty much any SIO2PC software.
To switch the interface to 1050-2-PC mode you need to flip one of the FTDI chip's GPIO pins, usually talking directly to it via libftdi/libusb (or the proprietary ftdi libraries). On other interfaces, like that Atarimax RS232, this was a bit easier as you just needed to toggle the (IIRC) DTR line.
In 1050-2-PC mode the interface is a bit awkward as it has the polarity of the command line inverted compared to all other 1050-2-PC interfaces. No big deal, but a bit annoying.
One of the largest obstacles with this interface though is that it doesn't provide +5V on the 5V/ready SIO line (it doesn't even have a connector for that on the SIO plug!). This took me quite some time to find out as I was wondering why I didn't get any response back from my 1050 - the 1050 will just act dead if the +5V/ready line isn't driven to +5V. So you need to manually provide +5V on the SIO line, eg by connecting a powered-up Atari to the SIO chain or by modifying the interface.
I mailed with Lotharek regarding that a couple of months ago, seems the interface was only tested with XF551 drives which don't need the +5V line to be driven. Haven't heard back from him since then so I'm nut sure if this has been fixed in newer versions of the interface.
Other than these issues I got the interface operating nicely in 1050-2-PC mode with AtariSIO/atarixfer.
MyDOS stores the ramdisk drive number in $070A, which is saved in the boot sectors when writing a DOS to disk.
In the MyDOS 4.53 source code (and in the MyDOS 4.53/4 DCM image from Mathy's site) the default number is 9, which gives you a ramdisk on D9:.
In the MyDOS 4.55 beta 4 source code (and DCM file from Mathy's site) the value was changed to 0 - which seems to mean "no ramdisk". No idea why that has been changed.
I've extracted the boot sectors which dir2atr uses to create bootable MyDOS images from the images on Mathy's site which means the current MyDOS 4.55 beta4 mode that I implemented in dir2atr last week has ramdisk support disabled by default.
I then also had a look at the 4.53/3 boot sectors, the image on Mathy's site has the ramdisk number set to 4, the boot sectors written out by dir2atr has it set to 8. Urgs.
This definitely needs a cleanup and fixing in dir2atr, and I'm inclined to change the default ramdisk number to 9 for all current MyDOS modes (4.53/3, 4.53/4 and 4.55 Beta4). I'm open to suggestions though, if there's a strong preference for using D8: instead I could use that as well. D9: looks like a better choice to me though as that allows D1:-D8: to be real disk drives and is the default in 4.53 source code.
NetBus or Netbus is a software program for remotely controlling a Microsoft Windows computer system over a network. It was created in 1998 and has been very controversial for its potential of being used as a backdoor.
In that case, why not utilize the DHCP server in the first place?
On a second thought that may not be too viable, people may want/need to use the router from their provider which typically has terribly crippled DHCP configuration options (sometimes none at all). Better use DHCP only to obtain a IP and DNS information, these things should work with all DHCP servers/routers.
TFTP could be used to retrieve client configuration but that requires people to install, configure and run a TFTPD server somewhere and managing configurations isn't too easy.
So I think it's probably best to keep the configuration on the client side, then people can change them rather easily, directly on their Ataris.
SpartaDOS X would probably be well positioned to play a role in a shared resource environment, since file system drivers can abstract file system operations to interact with (for example) a file server on a remote machine. The PCLINK (PCL:) driver is a good example of this: it implements a bi-directional file system protocol between the Atari and the PC's host file system (via SIO2BSD or the PCLINK implementation built into RespeQt).
Hmmm, do I hear someone volunteering to give it a try? :-)
IMO It'd be very interesting to explore if a NFS client implementation would be feasible. SMB is a mess, so better avoid that, and TFTP isn't really suitable for random access (which is a feature we'd might want to have). NFS server software is available for a wide range of platforms (yes, even Windows :-) and basically every NAS has built in support for that.
If NFS is doable then it would be interesting to make the Dragon "cart" V3 a real PBI device with flash ROM and RAM and whatever fancy bank-switching scheme is needed to make the code workable in the 2k pinhole (the hardware and PLD logic for that is no problem at all, software is the crucial and very time consuming part).
Instead of tying the file access code to DOS the device could register a, let's say, 'N:' CIO handler to give you access to eg "N1:>GAMES>PACMAN.COM".
With NFS client support in the PBI ROM the device could also intercept Dx: SIO calls and redirect them to (ATR) file access on the NFS server. And/or provide some simple game loader that lets you browse through your library on Nx: and start things.
Configuration could either be performed on the server side (BOOTP/TFTP or some DHCP options) or on the client (Atari) side. Maybe with a simple (external) configuration tool or (later) built into the flash ROM as well (like on the Black Box). Add a 3V lithium cell for RAM backup - like we did on the Turbo Freezer - and you have plenty of easily accessible non-volatile storage space.
No major changes since the last testing version, mainly documentation and other minor cleanups, but if you update from earlier versions of AtariSIO please have a look at the Changelog and README, a few command line options and other things have changed.
A big thank you to all who helped with testing or provided feedback, especially dl7ukk, you helped me a lot!
Yes, basically it's just this. After power-up (and after pressing reset) you can select the desired mode.
If you haven't used your Mega Speedy for quite some time you probably missed the firmware/software update from 2017 which fixed highspeed issues on NTSC Atari systems when using one of the Speedy modes.
So it's a good idea to update the flasher, config and Speedy slots with the latest version from my website.