flashjazzcat

Yeah: the web-interface is what I was thinking of. I'm sure that will help a lot.

Yes: it's potentially a big ask to expect a 16K application cart written forty years ago to work well with something which hopes to run a boot menu between the cartridge INIT and RUN vectors being called. I suppose this is where a) booting with the previously mounted set of volumes ready for use and b) being able to remotely mount images on the server side would be extremely useful.

Well, it would be pretty useful, but I guess there are good reasons why this doesn't happen yet. Of course the SIDE loader doesn't auto-mount FAT hosted ATRs, but you have persistently mounted HDD partitions for CONFIG.SYS, etc.

Ah yes - I vaguely remember some talk of the SDX drive polling causing FujiNet to get its knickers twisted. I had expressed interest in contributing to an SDX kernel driver for FujiNet, but have had no time to even remain adequately up to date on what's happening with the project.

Currently 127Kb/s (~12KB/s) for SIO unless POKEY is clocked via an external source. A PBI device may imply serial or parallel communications, but if you are asking about parallel IO transfer speeds (typically supported by but not confined to PBI devices) on IDE and SD card based devices, you can typically expect to hit 80KB/s. With IDE, for example, bandwidth is limited by only two factors: the response time of the ATA device as it seeks the requested sector and fills its internal buffer (which typically happens in a few MS), and the raw read/write speed of the CPU. Since latency with modern storage devices is so low, the Atari's CPU is the primary limiting factor; it is - for the most part - simply doing load/store operations, coded in the most efficient manner possible. DOS and OS overheads (as the system gets in and out of the PBI handler) will shave a bit off these figures. The SIDE cartridge running RWTEST on a PAL machine under SpartaDOS X will typically hit 64KB/s reads and around 55KB/s writes.

Doesn't FujiNet boot with the previously selected set.of volumes already mounted?

Surely FujiNet doesn't forget the mounted volumes every time it's powered off? You should find that almost any other device works well, anyway. I've never received so many emails asking for help with basic operation since people started buying FujiNet. Perhaps @tschak909 can provide some clear instruction, since SDX and FujiNet seems to be pretty much a known quantity at this point.

The default CONFIG.SYS will only install DOS under the OS if you don't have >128K, which you certainly should have with an U1MB. Just set the machine to 320K, 576K, or 1088K and SDX will load into banked memory, even if no custom CONFIG.SYS is found on the boot device. If you do want to make a custom CONFIG.SYS, just place it on an SDFS formatted volume attached on D1:, using whichever device you prefer. SDX never 'boots' a disk per-se. To boot from disk, type COLD /N at the SDX prompt, or turn off SDX entirely in the U1MB settings.

Fair enough. I've had to replace a dead RTC chip before, but maybe you blew the data lines on the CPLD going to the DS1305. I'm just thinking that it makes no sense to plan to replace the CPLD when it's much easier to replace the component which appears to have failed on an otherwise fully working board.

Sounds like the little DS1305 RTC chip is returning.nothing but zeros from NVRAM.

Yeah. I'm not gaslighting here. I just worked out (owing to the fact I recently exhausted a bag of 30 DIN13 connectors bought five years ago after I got sick of purchasing them piecemeal) that I have installed at least 30 VBXEs for other people, and thus something like fifty or more U1MBs. All U1MB machines assembled after 2015 had the FJC firmware flashed at divisor 0 with UFLASH. Because U1MB does nothing to affect POKEY, you could substitute U1MB for a Hias HSIO patched OS ROM or soft loaded patched OS and all of them would have run divisor 0 using the same FTDI/RespeQt/AspeQt setup. The only failures I experienced were caused by a fake FTDI chip and more recently by the fact POKEYMAX doesn't like the SIO caps on some 600XLs.

No serial floppy disk drive I am aware of supports anything near 127KB/s. I am asserting that SIO2PC (FTDI) works on every machine I have tested. Several 600XLs attain divisor 0 with SIO caps present, and many other machines don't have the caps in the first place. So the notion that hardware modifications are required or that results are inconsistent does not tally with my experience. Anyone capable of using cutters can remove caps. Your mileage may vary, of course.

Divisor 0 works consistently using Hias' driver and a geniune FTDI SIO2PC USB adapter on every single machine I have tested. You might have to snip some caps on the SIO data lines on some machines first, but sometimes not. Of course, anything not supported by XBIOS is bound to be written off by XXL as non-standard, difficult to accomplish, generally inconvenient. I use divisor 0 100 per cent of the time without transmission errors and have gotten used to it. Bare minimum daily driver configuration at this point, along with a PBI HDD.

Correct. The CPU is right at the front of the board and you would have no hope of closing the lid with Rapidus there. The adapter basically relocates the CPU socket to the top right corner.

An 800XL installation will require the Adaptus board. Perhaps Lotharek will sell one separately.

Most badly discoloured 1200XL I've yet seen:

Of course. There's also a video on the Toolkit page: https://atari8.co.uk/apt/toolkit/

The signals are labelled on the U1MB board itself which you can match up with any readily available Sally pinout; you can take all of them from the CPU if you don't want to hunt around for vias. https://lotharek.pl/productdetail.php?id=56 There's a clickable link on that page which shows the hook-up points on the CPU.

I've got two of those red UDMA adapters (one full-sized SD, one MicroSD) here and they work great on everything. Perhaps there are many bogus parts on the market.

Good to hear... especially since I forgot to upload the update (and I take this to mean I had already fixed the mentioned bug in version 0.29).

Observation and explanation. I had completely failed to mention what Avery pointed out already: that the relocating loader is not even necessary for PBI device support. If you look at the code in Avery's OS which actually polls for and invokes PBI device handlers, you'll see how concise and uncomplicated it is. As said: whether Atari exploited it or not, the PBI/ECI is quite widely utilised today, and not before time.

This SPARTA.SYS switch ensures that if OSRAM is used by drivers (in the absence of any extended memory), disk buffers will be taken from RAM at $C000-CFFF (under the OS). The parameter is ignored when banked memory is used (which it will be by default in the absence of 'USE' on the first line if the machine has >128K).

That's fair and reasonable.

I hear you, but the SIDE loader built into the U1MB (assuming one attempted to use the SIDE3 cart with no corresponding SIDE3 U1MB plugin) should report no SIDE/SIDE2 hardware found in the device menu when you attempt to use it with SIDE3. On the other hand, if you applied the SIDE3 U1MB firmware and run it with a SIDE2, the internal loader will start and find the cartridge, but find no supporting PBI BIOS (since it expects to see the SIDE/SIDE2 PBI BIOS). Sadly there is only room in the SIDE loader to probe the hardware that is supported (therefore it's not possible to report 'I found SIDE3 and I expected SIDE2'). On the HDD/PBI side of things, there are limited opportunities to report anything at all since the entire edifice is attempting to be more or less invisible to the OS, but you do have the 'U1MB SIDE3 PBI BIOS' message when you boot SDX, at least.

Plugins are now 2K in size, and Incognito can have them via a CPLD update. Of course there are a large number of combinations of device support in plugins, so that too is a headache to manage. This is what you'll get with external U1MB, and essentially what's already there with Incognito. If the mass storage device is built onto the board which also houses the PBI ROM, the two come as a package, so to speak. U1MB, on the other hand, now has PBI drivers for SIDE/SIDE2, XEL-CF, and SIDE3. Very flexible (one is not tied to any specific mass storage device), but a lot of work to maintain. Everything hardware specific to optional hardware components is now in the plugin. This includes VBXE now, so if you have no VBXE, there is no need to have the code to configure it in the firmware. Ideally, one would have a set of plugin modules all bank-switched in the same memory space, each with their own RAM, but such sophisiticated design hasn't gained much traction yet. Without such hardware support, one can either make all the plugin modules relocatable and design a means of embedding them into the ROM, or just do what I have done and have a plugin source file with everything in it, and bits turned on and off via assembler directives. So: I can churn out a SIDE3/Sophia 2/PokeyMAX plugin by editing a couple of defines and hitting compile. For the most part, including support for a device which isn't present does no harm (and settings for absent hardware are greyed out), so this at least cuts down on the number of different plugin ROMs I have to produce. But 2K provides enough space for stuff like the auto-loading NTSC VBXE palette, which is nice.