flashjazzcat

You can't physcially lay down tracks on a hard disk partition, so writing a blank file system is the correct procedure.

It's definitely wise to use pragmatic troubleshooting methods to try and narrow down the problems, but the more known issues there are floating around, the more difficult this becomes. The machines I referenced above were a mixture of stock and upgraded (U1MB, etc) Ataris which worked with SIDE2 but not SIDE3. Once 74LS08 was replaced, SIDE3 worked. But there's also one recently completed 600XL which turned out so well that the owner allowed me to hang on to it over Christmas so that I could complete the Sophia 2 plugin for U1MB. It was so solid and reliable (I tested it with the owner's SIDE3 cartridge right on the desk here) that I flashed U1MB updates to it for two weeks or so. But once it arrived home, suddenly SIDE3 is acting up with the display jumping around, etc. We appear to have eliminated problems on the machine (damage in transit, etc), and all that's left is the SIDE3 cartridge and the Lotharek PSU that the owner is using. Who knows if regulated vs. switching PSU makes any difference here? Who knows what other environmental factors exist? Once a potential culprit is identified (say, Phi2 cycle on the cart) and dealt with, at least we remove one variable, even the if all issues are not immediately fixed. It's completely demoralising when a machine I would have happily kept here and used every day for development exhibits all kinds of random behaviour when it's reunited with the owner.

There's absolutely no reason one should have to modify the host machine just to get the thing to work. I say this having done exactly that on a few machines, but only because no alternative course of action existed and it was supposed there was no problem with the timing on the cart. The main obstacle to delivery would probably be ensuring the deployment tool is reliable, but I regard this as a priority matter since I am getting pretty sick and tired of dealing with support emails concerning flaky SIDE3 behaviour.

How big is the APT (APT->Properties)?

If you can hang fire, there may be an FPGA solution in the offing.

You don't need the SIDE2 ROMs. As soon as you connect the SIDE2, regardless of what is on the ROM, with the PBI HDD activated, it should just work.

That would help, since the PBI BIOS for the SIDE2 will not drive the XEL-CF. This explains why you're not seeing the HDD. The two devices have registers at completely different addresses. To use the XEL-CF on a non-1088XEL/XLD system, you need to flash the standard U1MB firmware but then apply the XEL plugin, PBI BIOS, and loader.

Haha... fly over to the UK and I'll show you who is easily hurt.

It has everything to do with it if you or anyone else would like to see the matter addressed. That is the whole point, whether you like it or not. The mechanics of it the issue in the generic sense have been explained elsewhere. As to why XXL's stuff crashes: it's because he made it so. Simple as that.

The manner of delivery counts for a lot. Various quirks of Incognito are one thing if politely (albeit laboriously) highlighted, but deliberately capitalising upon a property of U1MB which - AFAIK - results in problems with a single-digit quantity of legacy titles which are apparently of little to no concern at all to all but one individual is quite another. Of course, in a civilised context, I advocate the timely addressing of known issues which cause actual problems. But on the other hand, it's a bit like 'cancel culture'. I doubt that fixing an issue about which 99 per cent of the noise is generated by a single voice would do much to endear the hardware to this particular individual. It has reached the stage that to capitulate now would give the impression that simply making a tremendous spectacle of yourself for months or years on end while simultaneously belittling the developer is a legitimate way to report issues. If what XXL is projecting is regarded as a 'contructive approach', the bar of human discourse has apparently reached the floor. At this point, a sensible way to proceed might be to somehow address the issue as described while rendering the recently developed software which exploits it in order to prove a point completely inoperable. I think they all do; I'm not sure about the quite uncommon unsocketed 600XL boards, however.

It's real. Try it.

Nice. In one case, replacing it with 74F08 fixed the problem, but in another instance, a.n. other 74LS08 was sufficient.

I don't want to jump the gun, since there seems to be a fair amount of uncertainty regarding settings and what they do, but I have so far had two machines here which required 74LS08 to be replaced before they would even 'see' the SIDE3 cartridge or allow it to function properly. Symptoms included black screen on power-up, booting as if there was no cartridge present, or intermittent booting of the loader but no or intermittent access to the SD card.

OK. I'm not trying to be a pedant, but I assume you mean BIOS and PBI BIOS. You need the SIDE3 version of both. In any case, I've seen the boot to black screen thing before and it's not a software issue. It can't be a bad flash either if you're able to start the loader intermittently or by other methods.

Be sure that you updated the PBI BIOS, in that case. It should report 'U1MB SIDE3 PBI BIOS' or words to that effect when you boot SDX from the U1MB. Wrong PBI BIOS is the most logical explanation. The update process is not working (and reporting nonsense current version data) because there is a ROM in the way of the cartridge. The safest way to update using SIO2SD is by turning off SDX and the PBI HDD on the U1MB, and booting SDX from the SIDE3 cartridge. Launch the XEX there and you should be good. I still have to update the documentation for all this stuff; this is proving a monumental task after weeks working on the firmware itself, but hopefully a written reference for these comparartively new tools will be helpful. To eliminate issues with the SD card itself and ensure you are running the correct loader regardless of any other settings, disable SDX and the PBI HDD on the U1MB and power up the machine with the SIDE3 switch in the 'up' (loader) position and see what happens. The loader should automatically start and read the contents of your SD card. It would be worth noting the results of this simple test. Once you know the card is readable, you can update the loader directly from the FAT partition by starting it from the SIDE3 loader.

I have a few 800XL boards here with gold plated PBI contacts, but they're in the minority.

I wrote a DS1305 RTC driver for Sparta 3.x, BeweDOS and RealDOS. All TD does is read the date and time via the RTC driver; the TD line is therefore wholly abstracted from the clock hardware. For info: one bug (the TD line interfering with SD card IO) was caused by CRITIC not being set in the LSIO driver (SIDE3.SYS). I had assumed SDX would set this prior to calling the driver, but it doesn't. Setting CRITIC prevents the TD line from calling the RTC driver during the VBL while critical IO is taking place, which is important, since accessing the clock right in the middle of a FIFO sector transfer did not go well.

The loader has no impact on whether the HDD works under SDX or any other DOS. If you have flashed the proper main BIOS and PBI BIOS to the U1MB, enabling the PBI HDD in the settings should allow FDISK to detect the hard disk. There is no SIDE3 loader version 3.10; what you are likely seeing is the loader built into the U1MB, because you haven't enabled the hard disk in the settings. Once the HDD is enabled, 'L' runs the loader on the cartridge rather than the one built into U1MB. You can then update the loader by placing the XEX on the SD card and launching it directly from the 'SIDE3 loader'.

Let me just stop you right there.

Everything should be available here for UK customers... eventually: https://retrolemon.co.uk/12-atari

Tried a 128K machine: still works. Be sure you have the latest ROMs from my website, and use the corresponding SIDECFG.XEX (i.e. the most recent, on the toolkit disk). Eric's OSS patches are a black box as far as I'm concerned, although if I could actually duplicate the issue, I'd be happy to at least look into it.

OK. I was (am) confused, since in your initial post, you write 'no sparta dos loaded'. There are two generations of SpartaDOS: disk-based (SpartaDOS 3.x, etc), and SDX. So you are saying that SpartaDOS X is active and you are invoking BASIC XL with the 'CAR' command? If this is the case, I cannot reproduce it here. I boot SDX on from the SIDE2 on a 1MB machine (no U1MB), type CAR, and BASIC XL starts. I press reset, it takes me to the 'Ready' prompt. I type 'DOS', it takes me back to the SDX prompt. How much RAM is on the machine? Are there any other configuration details we need to know about?

It is patched (by ebiguy) to run on the SIDE2.

I see. Thanks.

Is any DOS present at all? If not, DOS will invoke the self-test.