flashjazzcat

Well, finally got my new Linux Mint 16 install up and running, and I still can't get Altirra to use a CF card as a hard disk image. Never mind write capability, I can't even get the same read functionality I enjoy in Windows 7. Puzzling. Other than that, everything works great in Wine, once I'd sorted out Wine's audio settings (until I'd done that, Altirra was running REALLY slowly).

No offense taken! I have no objection to assisting you out here on the forums rather than via PM if that's what you prefer. Indeed, it may be useful to others if we ever get to the bottom of the issue. What's not useful to others (or to us) is to start drawing conclusions as if the root cause of the issue is being narrowed down, when in fact it appears to me that you nor I (nor anyone else who has spoken up) have any real idea what the problem is. It often happens, of course, that people get frustrated when things don't work and they want to blame the hardware or the software. I've done it myself; sometimes I was right, but sometimes I was wrong, and it transpired I'd been making some repeated user/installer error. As for the boot to Basic / Self-test thing: well, I really thought for a moment that I'd managed to replicate the issue in emulation there while setting up Altirra in Wine on Linux Mint 16. No way, no how would the emulated U1MB machine boot an ATR, but it was possible to read and write to them. Well, it turned out I'd forgotten to check "SIO Override detection" in Altirra's disk settings, so the Atari wasn't even attempting a PBI boot. I really thought I'd discovered some (admittedly completely perplexing) software issue there, but it was the kind of user error I describe above. Good. Well, now we get to the bottom of it. These CF cards are "block" devices, so providing the controller can reliably read sectors (and react to IDE busy states, etc), it will basically work. By a "bad" CF card, we usually mean something which causes timing issues which result in transmission errors, and once reliable communication between the Atari and the media has been lost, well - naturally not much will work reliably. So, how "bad" does it have to be? Not very would be the answer, since if a dropped byte and a double read occur at the hardware level when the PBI ROM is reading a sector, there's no programmatical method of determining what data is invalid (unless we apply our own checksums to sectors, but fortunately the days of software error correction in hard disk drivers seems to be at an end, otherwise we'd still be enjoying 25KB per second transfer rates). In short, the drivers tend to assume that the controller is at least communicating reliably with the device. Repeated transmission errors (which I must say are unusual with modern controllers) would result in a non-booting ATR if when the Atari was booted for the first time (with the CF card in place, and before running the SIDE Loader), the PBI ROM was unable to identify the FAT on the card. It would then fail to register the first FAT partition in the RAM-based partition table. However, it would also report an error to the SIDE loader when the latter attempted to mount the disk image. No problem - and my pleasure. I don't mean to seem like I'm overreacting. It's just I'm as frustrated as you are, in a way, and it's essential that we are utterly pragmatic in diagnosing the issues at hand. Of course there's always a "fear" that software will be to blame (after all, it's possible), and drivers like these are especially critical things. I hate to think of some lurking issue that we can't nail down however hard we try.

Unfortunately, owing to the ad-hoc testing strategy and the unrepeatability of your issue anywhere else (thus far), it's a little bold to point the finger at the software. I've asked that you prepare a CF card from scratch with FDISK; please do before speculating further. If a CF card proves troublesome, that's a hardware issue.

Which reminds me: it screws up one's physical printer output. One check box next to "Emulate Printer" is required.

Drac030 has told me he will update the IDE Plus 2.0 PBI BIOS to remove the compatibility issue with the FDISK's newly introduced "global metadata flag". This is excellent news, and means that a final release of all the APT tools is but a short time away.

FDISK 4 does not require SDX. You can use it with any DOS you want. Likewise MATR. Note the older FDISK versions will be deprecated once FDISK 4 final is released. Well, the MBR you posted should be perfectly usable, but I'd strongly recommend flattening the card in Windows or using FDISK just so we have all bases covered, and lest we end up looking back on a testing strategy which deftly managed to ensure at least one thing was always broken, while others were fixed.

Thanks for those! Quite an interesting MBR in the first screengrab. It is indeed a valid MBR partition table: type $0B is FAT32 with CHS addressing, which I guess is OK (and what U1MB used until it was corrected to type $0C, which is FAT32 LBA addressing - nevertheless the PBI will pick up type $0B as well). The CHS values (ironically) are missing from the partition entry, but again this won't cause an issue on the Atari side, since APT FDISK only adds the CHS values to the partition table (and aligns the FAT on cylinder boundaries) for legacy compatibility reasons. I have no idea how MyBIOS goes about aligning and creating partition entries, but I kind of wish you'd just try a factory fresh card, or at least something partitioned from scratch with FDISK 4 instead of being prepared with MyBIOS. It might be fine, but you're trying to get APT stuff to work with APT software, and bringing a third party partitioning utility into the fray just seems to be adding unwanted complication. I think you mentioned you'd already tried factory-fresh FAT formatted CF cards, though. The PBI ROM doesn't care whether or not the active (or boot) flag is set on the partition entry in the MBR, BTW. So - the PBI ROM should grab the partition entry at power-up, read the FAT32 boot sector, and store pointers to the FAT and Cluster area in readiness for the SIDE Loader issuing a mount image command. FAT boot sector should be fine, since Windows prepared it, and I've heard of no compatibility issues in that area.

Something I just noticed after all this time is that the SIDE loader can only be invoked from the U1MB BIOS menu (via the "L" key) if SpartaDOS X is enabled. Otherwise the machine just reboots. I'm sure there are excellent technical reasons for this which I have forgotten about. Sooooo... ensure you have SDX enabled in the Ultimate menu.

No problem man... when you get time. The fact the combo works makes me think we should explore ALL the less-obvious possibilities.

No possibility of posting MBR as I requested in the other thread?

Brilliant! You're absolutely right. I'd never have thought of that.

Noticed this rather odd trail left by the raster beam while single-stepping:

Certainly, using an existing SDX driver which I'll release. No booting, though, and SDX is required.

Found a bug in the PBI ROM which would prevent a mounted ATR from working if there's more than one FAT on the card and the ATR is in the first FAT. I doubt this affected anyone, however, and it still doesn't account for the reported XEGS issue. Fixed in upcoming upgrade.

MATR nearly finished:

A PBI ROM which observes the APT (Atari Partition Table) specification, described here. TXG/MNX was obviously interested in using FDISK 4 (the partition editor for APT) with his BB.

I'd suggest 4:3. You'll typically see vertical black borders on a 16:9 display.

Indeed! I mean this (below)...

Obviously your ears were burning.

Where did you read the bit about it being a hack? It's a damned sight easier than writing an editor (especially when you don't have a GUI to hand), and personally I'm all for plain text files rather than uneditable binary blobs. This is why I changed all the config files in The Last Word from binary to plain text. I'm sure upset and shocked to discover how much of a user-unfriendly hack that is. As for complexity: it surely depends on what you consider complex. All you're looking for is an identifier (say - an ATASCII code), followed by an equate symbol, followed by the macro text. That's not really a complex project. Well, you'd have to delve into the SDX programming manual, I guess. C++ is not an absolute requirement for reading the SDX environment with a few dozen bytes of code. But there's absolutely nothing wrong with the current method at all. It has the advantage of being reasonably generic, easy to understand (from the user's point of view), and simple to implement. Anyway - I won't disagree that it's a pain making uniform functionality work across different DOSes. A few minutes ago, doctorclu's suggestion was deemed "a good idea", but now (following a couple of suggestions on how it might be implemented), it's obviously become an almighty pain in the ass. I'm perfectly happy with the current arrangement, and was merely throwing in ideas. Please ignore them, and don't misinterpret my suggestions as implicit criticisms of something which works just fine as it is. Sheesh. BTW: It was someone else who'd asked me about finding config files a while back.

Ebay don't give a toss about anything, as long as they get their percentage from sales. I reported an abusive loony seller's PMs a couple of months back, and never even got a courtesy reply from customer services. You might as well shout in outer space.

Macros are cool, of course. If you don't want to code up an editor, just make them plain text files. As for config file locations - I take it the user is running a hierarchical filing system. If it's SDX, get the application to read the config file from the DOS PATH, or observe some (optional) environment variable containing the absolute path to the config file. It's appreciably different with other (lesser) DOSes, but there's always a way. I think we chatted about a few of the approaches LW uses a year or so back.

Yeah - for the purpose of mounting ATRs and running XEX files you should be fine with just a single large FAT partition covering the whole card, i.e. with the boot record in sector 0 (instead of an MBR partition table). For the purposes of your testing, however, an APT might also be a useful means of verifying HDD operation via the PBI ROM. Just use FDISK to give yourself a large FAT and a few hundred MBs of APT. Note the APT HDD is totally independent of SDX. The only time you require SDX is if you're using the "soft driver" (i.e. if you don't have U1MB PBI functionality). We already know the CF interface of your SIDE2 works, though (since you can run XEX files), so using the soft driver won't prove anything. Should be very soon indeed. I'm just putting the finishing touches to the MATR utility, which now allows you to select the APT PBI device to use, and which FAT on said device (assuming there's more than one partition). I've been flat-out finishing these tools, actually, to the exclusion of all else, since managing them is like the trials of Sisyphus. I must apologise to those who have sent me emails and not received replies yet this past week... I've been grabbing spare moments between family visits, etc, this weekend, to get this stuff done. Speaking of emails - I'm still waiting to hear from Drac030 regarding the "global metadata" bit issue with IDE Plus 2.0. I'd like this minor incompatibility rectified (on one side or the other) before releasing FDISK 4 (which is finished and waiting). All that's required is a change to the operand of a single AND instruction in the IDE+ BIOS, assuming that's the agreed solution arrived at. PBI ROMs for Incognito and U1MB are done and ready to roll (just being tested). Minor changes to the soft drivers (for SIDE and MyIDE) will not take long. Anyway: I really want this stuff out of the way this week if possible, so I can focus on the GUI to the exclusion of all other Atari matters. No, because there's no APT BIOS for the Black Box. Nor is there one for MIO (although Steve Carden was trying to convince me to think about writing one the other week). Like I say, though - the trials of Sisyphus.

When implementing a soft-reboot feature in the new (unreleased) PBI ROM, I discovered that a common way of ending up in the Self-Test following a reboot is by leaving the PBI ROM banked in (instead of the FP package). This causes the ROM checksum to fail, which brings up the Self-Test. Now, quite why that's happening in your case, I'm not sure, and sadly of all the machines in which I have U1MB installed, none are an XEGS. The nearest I can manage here is to emulate the set-up in Altirra (XEGS, U1MB, 1088KB, SDX on), and ATR booting works flawlessly using the exact same XEX loader and PBI ROM as on your system, as well as with MATR. Moreover, I have NEVER experienced the kind of issues you describe with ATR mounting, regardless of the set-up, either in emulation or on real hardware (real hardware in my case being 65XE, 1200XL, 600XL and 800XL). So really, without being able to replicate the issue in emulation (and not being in possession of a Turbo Freezer or similar equipment), while I'm dying to track this problem down for you, I'm at a loss where to begin, the first step being replicating said issue. Mounting should be instantaneous regardless of the PBI ROM version: all that's happening is that the SIDE loader is passing the starting cluster number of the ATR to the PBI ROM. The PBI then opens the file, checks the ATR header, sets up density, etc, and mounts the image just like it was an HDD partition. The SIDE loader also informs the PBI ROM that the next reboot should boot from D1: (in case the HDD was set up to boot from D3:, for example), disable BASIC if necessary, and so on. The computer then does a coldstart, and boots from the ATR (the partition table in RAM surviving reboot) just as if it were a hard disk partition. The only change I can recall making which (possibly) made it into the latest publicly available PBI ROM was to remove the code which disables the external cartridge when the system is booted with SIDE hardware on, with button... this was done at Candle's request for reasons which now escape me, but everything still works here just the same way. As I say, I would love to nail this issue, but since Candle's suggestion regarding the XEGS mode jumper hasn't done the trick, I don't know how to assist right now. I'm sure, mind you, that yours is not the only U1MB equipped XEGS on this planet (I have seen photographs of another), so there has to be someone else who can verify ATR/HDD operability on this hardware platform. About the only potential culprit I can think of in the meantime is the FAT partition on your CF card... and even that's a tremendous long-shot. If you could dump sector 0 of the card (the MBR, if it has one), plus any FAT boot records (first sector of FAT partition), I'd be delighted to have a look so we can eliminate software issues from the mix.

Just to keep things rational: even if the seller had emailed the admins of the originating site (DLT, that is... and they appear not to give two hoots, despite having written a lot of original code), he'd still require a good degree of historical knowledge to realize he should also consult yourself and Mike... unless DLT had referred him to you. So - given DLT don't care - the fellow is operating out of ignorance of SDX's noble and diverse lineage. So perhaps you should begin by alerting him to his mistake.