APT Hard Disk Preparation and Utilities

[atari8warez]

This reminded me to dust off my old Shakespeare books

[+phoenixdownita]

I wasn't being sarcastic, mind you guys.

 

I really envy fjc for his prose.

I apologize if my remarks sounded as criticism in disguise, that wasn't the intention.

I really wish I had the time, dedication and opportunity to develop the skill myself.

 

Sorry if I interjected, this after all is a thread about "APT Hard Disk Preparation and Utilities" and I for one don't desire in the least for fjc to withdraw his contributions.

At the same time I do not wish a8w to stop sharing his tools either. There's place for both, the world is beautiful because of its variety and not in spite of it.

 

So please fjc and a8w keep on sharing

Thanks.

Edited January 30, 2014 by phoenixdownita

[Marius]

I wasn't being sarcastic, mind you guys.

 

I really envy fjc for his prose.

I apologize if my remarks sounded as criticism in disguise, that wasn't the intention.

I really wish I had the time, dedication and opportunity to develop the skill myself.

 

Sorry if I interjected, this after all is a thread about "APT Hard Disk Preparation and Utilities" and I for one don't desire in the least for fjc to withdraw his contributions.

At the same time I do not wish a8w to stop sharing his tools either. There's place for both, the world is beautiful because of its variety and not in spite of it.

 

So please fjc and a8w keep on sharing

Thanks.

 

But my response wasn't sarcastic either! I agreed with you, and I thought it was very cool to see that Google Translate was not smart enough to translate FJC's posts into something readable in Dutch.

[flashjazzcat]

Well, the APT reboot was somewhat delayed, but this is fortunate since it coincided with ProWizard providing some really excellent test results from his new Ultimate and SIDE hardware.

 

UMPBI06.XEX

 

This is a test update of the Ultimate PBI BIOS pending a proper release, hopefully in a few days.

 

Changes/Bug Fixes

• Critical bug whereby other SIO devices (such as "R:") would become unresponsive when the PBI was enabled has been fixed
• Page zero locations 0x3D-3E are no longer used by the PBI BIOS. Their use prevented some versions of SpartaDOS 3.x and RealDOS from booting, either as mounted ATRs or bootable APT partitions. Strictly speaking, DOS should not use these locations at all, but their (mis)use is so widespread (for reasons unknown, when any "safe" page zero locations could reasonably be employed during the boot process) that I have amended the BIOS for the sake of compatibility.
• Experimental support for "padded" double-density ATRs has been added. Padded DD ATRs typically have 384 bytes of dead space immediately following the three single-density boot sectors. I have found a way to detect these non-standard ATRs without recourse to anything but the ATR header itself, but I want to know if a) it breaks anything which previously worked, and b) if it's worth keeping the new code or not. I have so far encountered only one non-standard ATR, containing SpartaDOS 3.3a. However, it now works flawlessly.

AA member ProWizard has been entirely and solely responsible for bringing the issues which led to these important changes to my attention. He has kindly offered to test a wide range of "problematic" ATRs on an ongoing basis, but in the meantime the SIO device fix (which is probably what was preventing my P:R: Connection from working) is critical enough to warrant an official release of the update in its current form at the earliest possible opportunity. The fix is pertinent to Ultimate, Incognito, SIDE and all APT devices (not including IDE Plus, obviously), and will be released as part of the slew of APT updates very shortly.

 

In the meantime, any feedback on the attached PBI BIOS would be warmly welcomed.

 

[+Roydea6]

Damn my Atrs are now booting with Ultimate.

This seems to have fixed my problem.

 

Bois option 'L' works a lot better.

Fat32 loader works a lot better.

Matr(2) has always worked mounting, but now also boots if asked.

 

4 Stars ****

[flashjazzcat]

Wow - thanks Roy! Can you share some of the previously non-working ATRs? I need to evaluate whether the new DD code has any part to play.

[flashjazzcat]

Fixed ATR sector caching issue when accessing multiple mounted images (thanks ProWizard, again)...

[+Roydea6]

Wow - thanks Roy! Can you share some of the previously non-working ATRs? I need to evaluate whether the new DD code has any part to play.

ALL of them didn't play well with the previous PBI rom, K-file--90k sized, MyDos - different sizes, sdx33a--different sizes, SDX44x 32mb 512 bps, Game atrs from Holmes.

But now all of the above boot very well, I have ran through my most favorite game atrs and they all boot.

[flashjazzcat]

That's excellent news Roy. I had no idea that malformed ATRs would be so frequently encountered.

 

I'm just finishing changes to the SIDE/MyIDE drivers and the APT ROM for IDEa, and barring any further issues I'll aim to get everything online by Sunday. I've still got to write documentation and do some website updates too (this is what I was about to start on Wednesday before the latest round of frenzied coding started).

Edited February 7, 2014 by flashjazzcat

[drac030]

I do not think SD or DD512 ATRs can be considered "malformed" ;P

[flashjazzcat]

I do not think SD or DD512 ATRs can be considered "malformed" ;P

 

I'm not suggesting they are. The only change in this BIOS with regard to ATR handling is provision for malformed double-density ATRs with padding after the boot sectors. If Roy has found that ATRs in other densities which adhere to the spec have miraculously started working for some reason, all well and good. Personally I always found SD and DD512 ATRs to work, but I'm happy that Roy has a broadly working collection now for whatever reason.

[flashjazzcat]

Last driver update finished:

 

 

[+phoenixdownita]

Just upgraded to PBI 0.6 and now all flashing ATRs boot fine from my SIDE2, TRG or U1MBRomGen generated .... guess it had to do with TRG SDX 3.3, maybe "Page zero locations 0x3D-3E" fix has something to do with it.

 

I also tried my DaneElec CF, the troubled one, some exact U1MB setting as the previous ATRs boot via same SIDE2, but no dice, attempting to boot to ATR goes to self test.

[Just reporting it here, I know that fjc swears by a bad media quality diagnosis and I stubbornly stick to alternative explanations ].

 

In any case PBI 0.6 is definitely a step in the right direction for people that are attempting to use SIDE2 as the only way to use ATRs and to take care of their U1MB flashing needs.

Edited February 8, 2014 by phoenixdownita

[w1k]

pbi 0.6?

[+phoenixdownita]

I used the XEX here http://atariage.com/forums/topic/210754-apt-hard-disk-preparation-and-utilities/page-13?do=findComment&comment=2922287

to flash and it reports 0.6.

[flashjazzcat]

I also tried my DaneElec CF, the troubled one, some exact U1MB setting as the previous ATRs boot via same SIDE2, but no dice, attempting to boot to ATR goes to self test.

[Just reporting it here, I know that fjc swears by a bad media quality diagnosis and I stubbornly stick to alternative explanations ].

I've told you before and I repeat: your bug reports have hitherto implied that "nothing works", and included no further details. "Boots to self-test" as a generalised symptom is demonstrably inaccurate, hence the assumption your hardware is fucked up. I've been working long hours with Prowizard's specific testing information, and making excellent headway. Without evidential examples of what's broken, there's little I can do. Sitting and testing every ATR on the planet on my own is not a very realistic proposition. I'm working on this for purely philanthropic reasons. Edited February 8, 2014 by flashjazzcat

[+Ripdubski]

'm working on this for purely philanthropic reasons.

And the rest of us appreciate your many contributions to the community!

[flashjazzcat]

Can someone test this, since it appears two independent examples may be insufficient: install SpartaDOS 3.x on a bootable DD hard disk partition (SIDE hardware enabled, with button), disable SpartaDOS X via the Ultimate menu, save settings, power off the computer, then power on again.

 

Use PBI ROM from this post: http://atariage.com/forums/topic/210754-apt-hard-disk-preparation-and-utilities/page-13?do=findComment&comment=2922287

Edited February 9, 2014 by flashjazzcat

[+phoenixdownita]

I've told you before and I repeat: your bug reports have hitherto implied that "nothing works", and included no further details. "Boots to self-test" as a generalised symptom is demonstrably inaccurate, hence the assumption your hardware is fucked up. I've been working long hours with Prowizard's specific testing information, and making excellent headway. Without evidential examples of what's broken, there's little I can do. Sitting and testing every ATR on the planet on my own is not a very realistic proposition. I'm working on this for purely philanthropic reasons.

Apologies, I believe that short of sending the crappy CF directly to you I won't be able to put in word what exactly happens and not giving you anything to work off of.

Preemptive apologies for the wall of text following here.

 

I have 2 distinct CFs (the crappy and a good one) with half their size devoted to FAT32 and with pretty much the dump of ataripl online archives plus a bunch of flashing ATRs in it, the same ones on both cards.

 

Taking PBI out of the equation for a moment [literally disabling it from U1MB bios], and to recap I am successfully able to use the crappy CF with MyIDE2 [all features] and with SIDE2 [all features]. SDX for MyIDE2 or the embedded SDX on SIDE2, thru their relative FDISK 1.0 see the crappy CF device and allow me to partition it, I can then successfully create entries into the APT portion and format them etc...

 

You already explained to me that "non PBI" support for SIDE2/MyIDE2 devices within SDX is done thru a soft driver that is different to PBI, although it may come from much of the same code it doesn't have to deal with a lot of the complexities the PBI counterpart has to.

 

XEXs launched from any CF FAT32 portion on either MyIDE2 or SIDE2 can use the extra RAM onboard the U1MB, obviously SIDELoader embedded on SIDE2 and FAT32Loader for MyIDE2 can see the FAT32 partition and its content correctly, allow me to select and launch all that they support.

Not an exhaustive test by any means just something that hints to me that my soldering job to install U1MB is fine as well as the hardware [in a generic sense] at least relative to the tolerance that the SW embedded in these devices allows it to be. I have to state this point because for long time I was told I probably did something wrong in the soldering department.

 

Now as soon as I activate SDX on U1MB with support for SIDE2 (with button) the crappy CF is distinguishable from the good one. In this situation I am using SIDELoader in U1MB obviously ("L").

Still the FAT32 is perfectly accessible and support for XEXs works flawlessly, I can start them and I see the SIDE2 led flash as the XEX loads and everything is peachy.

Now if I select an ATR, any ATR, that's when I can't boot it. Also If I let SDX from U1MB boot I can't see the media or any partition I may have created in the non FAT32 portion [created thru the onboard SDX via SIDE2, not the onboard U1MB SDX]. The good CF does not have these problems at all.

 

My hypothesis as to why are:

1) crappy CF specimen, something wrong with this particular one that so far has only manifested itself via PBI but nonetheless hardware related

2) the CF type, all specimens are simply not good, brand to avoid

3) SIDELoader and/or PBI sw trip on bad information/non std information regarding the CF or the FAT32 on it

4) like 1 but only wrt my specific instance of SIDE2

 

1 is the current most likely cause in your opinion, and indeed very possible.

2 is a little scary because once there's one brand that has issues there may be more and it will be nice to start tracking them so new buyers would know what NOT to buy wrt "SIDE2+U1MB+ATR booting".

3 can only be diagnosed by hardware debugging meaning I send the CF to you. The only other way would be for SIDELoader to have a debug mode in which it prints to screen what info it puts in memory for PBI consumption so we can try to track something, I am not sure what PBI could do to help debugging as if it really trips on bad HW/info that make it "self test" or "boot to basic" it may not have a chance to print anything on screen.

4 I would need another SIDE2 to try it out but I believe to be unlikely the case

 

I don't think ATR support per se inside PBI is broken, quite the contrary it gets better and better.

 

Short of sending the CF to you, do you have any suggestion as to what to do next to attempt to track the cause down, even if it only impacts me?

 

And the rest of us appreciate your many contributions to the community!

I do appreciate his works a lot. Don't take my words as criticism, they are not. I am a little obsessive in root cause analysis, for better or for worse, but last thing I want is spread beliefs that fjc work is not good, nothing further from the truth.

[flashjazzcat]

Apologies, I believe that short of sending the crappy CF directly to you I won't be able to put in word what exactly happens and not giving you anything to work off of.

Preemptive apologies for the wall of text following here.

 

I have 2 distinct CFs (the crappy and a good one) with half their size devoted to FAT32 and with pretty much the dump of ataripl online archives plus a bunch of flashing ATRs in it, the same ones on both cards.

 

Taking PBI out of the equation for a moment [literally disabling it from U1MB bios], and to recap I am successfully able to use the crappy CF with MyIDE2 [all features] and with SIDE2 [all features]. SDX for MyIDE2 or the embedded SDX on SIDE2, thru their relative FDISK 1.0 see the crappy CF device and allow me to partition it, I can then successfully create entries into the APT portion and format them etc...

 

You already explained to me that "non PBI" support for SIDE2/MyIDE2 devices within SDX is done thru a soft driver that is different to PBI, although it may come from much of the same code it doesn't have to deal with a lot of the complexities the PBI counterpart has to.

Yes - the soft-drivers have a broadly similar codebase to the PBI ROMs now, although the drivers which fully realize this uniformity have not yet seen release. They would have been released this week, were it not for ProWizard's timely observation of some hitherto overlooked issues with the existing PBI BIOS and soft drivers. Anyway: for interest, the soft-drivers for SIDE, SIDE2, Colleen, MyIDE (internal and external), and MyIDE II are all now built from the exact same code base, with subtle differences such as the IDE base address, hot swapping capability, drive reset, etc. Similarly, the PBI ROMs for Ultimate and Incognito are built from the exact same codebase. The IDEa APT driver is a separate entity, meanwhile, although it's more or less a PBI version of the soft-driver.

 

So when these drivers are released, everything really will work identically right across the board. However, at the moment I think people are using a motley collection of soft-drivers (I noticed one person using FDISK 4 with SIDE Driver 1.0 the other day), and this the kind of thing I want to try and eliminate.

 

XEXs launched from any CF FAT32 portion on either MyIDE2 or SIDE2 can use the extra RAM onboard the U1MB, obviously SIDELoader embedded on SIDE2 and FAT32Loader for MyIDE2 can see the FAT32 partition and its content correctly, allow me to select and launch all that they support.

Not an exhaustive test by any means just something that hints to me that my soldering job to install U1MB is fine as well as the hardware [in a generic sense] at least relative to the tolerance that the SW embedded in these devices allows it to be. I have to state this point because for long time I was told I probably did something wrong in the soldering department.

Understood. As I said before, I can only speculate on the causes of problems when someone reports that "nothing works". The code which loads XEX files was written by Candle, while the code which handles ATRs was written by me. He might unroll his loops a little differently, he might be reading full clusters at a time (multi-sector reads), and any hardware which exhibits any instability will likely behave a little differently depending on the software interfacing with it. ATR mounting works (albeit imperfectly), and the impression I was getting was that - in your case - not a single ATR would mount. So, given that other users can mount at least some ATRs, it seems likely that someone who can mount none at all has additional problems. But as I say: this is speculation. Prowizard adopted the strategy of sending me specific ATRs which would not work for one reason or another, and I have spent five days working through these one at a time. All but one (out of around a dozen representative examples) now work.

 

Now as soon as I activate SDX on U1MB with support for SIDE2 (with button) the crappy CF is distinguishable from the good one. In this situation I am using SIDELoader in U1MB obviously ("L").

Still the FAT32 is perfectly accessible and support for XEXs works flawlessly, I can start them and I see the SIDE2 led flash as the XEX loads and everything is peachy.

Now if I select an ATR, any ATR, that's when I can't boot it. Also If I let SDX from U1MB boot I can't see the media or any partition I may have created in the non FAT32 portion [created thru the onboard SDX via SIDE2, not the onboard U1MB SDX]. The good CF does not have these problems at all.

 

My hypothesis as to why are:

1) crappy CF specimen, something wrong with this particular one that so far has only manifested itself via PBI but nonetheless hardware related

2) the CF type, all specimens are simply not good, brand to avoid

3) SIDELoader and/or PBI sw trip on bad information/non std information regarding the CF or the FAT32 on it

4) like 1 but only wrt my specific instance of SIDE2

 

1 is the current most likely cause in your opinion, and indeed very possible.

2 is a little scary because once there's one brand that has issues there may be more and it will be nice to start tracking them so new buyers would know what NOT to buy wrt "SIDE2+U1MB+ATR booting".

3 can only be diagnosed by hardware debugging meaning I send the CF to you. The only other way would be for SIDELoader to have a debug mode in which it prints to screen what info it puts in memory for PBI consumption so we can try to track something, I am not sure what PBI could do to help debugging as if it really trips on bad HW/info that make it "self test" or "boot to basic" it may not have a chance to print anything on screen.

4 I would need another SIDE2 to try it out but I believe to be unlikely the case

 

I don't think ATR support per se inside PBI is broken, quite the contrary it gets better and better.

 

Short of sending the CF to you, do you have any suggestion as to what to do next to attempt to track the cause down, even if it only impacts me?

The best way to completely eliminate hardware issues is to run the specimen ATRs in emulation. Altirra is so good now that if something works there, you can be reasonably sure it should also work on real hardware. So the first job would be to image your cards, and email them across with copies of the Ultimate ROM you're using. I'd set these up in Altirra, and anything which didn't work would hint at an incompatible ATR, or some issue with the PBI code. If everything worked in the emulator, then the conclusion speaks for itself.

 

I'll write a changelog for the forthcoming PBI BIOS, but for now I can honestly state that only two "bugs" were found: issues with the PBI passing command frames up the SIO chain when DDEVIC was not $3x or $20 (which you'd only notice when attempting to use - for example - a modem), and a bug in the ATR sector caching which really only manifested itself when using more than one ATR at a time (in the sense of copying files between them, etc). Everything else I have changed has been a concession to things not following standards: padded ATRs, and software which insists on using $30-$3F during its boot process. That's pretty much it, and it's the concessions towards compatibility with broken ATRs and software which ignores the OS documentation which is yielding the greatest compatibility improvements, and by a country mile.

Edited February 9, 2014 by flashjazzcat

[+phoenixdownita]

...

The best way to completely eliminate hardware issues is to run the specimen ATRs in emulation. Altirra is so good now that if something works there, you can be reasonably sure it should also work on real hardware. So the first job would be to image your cards, and email them across with copies of the Ultimate ROM you're using. I'd set these up in Altirra, and anything which didn't work would hint at an incompatible ATR, or some issue with the PBI code. If everything worked in the emulator, then the conclusion speaks for itself.

Not sure how to "image" the whole card, any suggestion, like what tool to use?

[ideally I would like to capture all the HW related info as well in case it has to do with some of those fields being misused by the manufacturer, if indeed they are accessed at all during the chain that leads to an ATR successful booting out of a SIDE2 via U1MB SIDEloader]

 

But logically speaking the fact that if I take the same ATRs and put them in the good CF they work wouldn't rule out inherent ATR related issues and leave us with the crappy CF either being the cause per se or tripping a border case/unexpected/unplanned behavior somewhere on the SW chain?

[i say that because on the crappy CF no ATR that I tried has ever been able to boot over SIDE2, the same ATRs on the good CF have no issues, also putting the crappy CF on MyIDE2 and use FAT32Loader to boot those same ATRs succeeds thus anecdotally showing that the FAT32 content of the crappy CF in principle should not be corrupted]

 

For my own education do you mind explaining the steps that happens during the process from a point of view of information exchange among the pieces?

Just trying to figure out how many SW pieces have to play in concert to make this to work.

If it's considered Intellectual Property then obviously never mind.

 

...

software which insists on using $30-$3F during its boot process

...

With regard to the good CF only, gut feelings tell me that this is what unblocked TRG flashing ATRs starting up correctly for me now over SIDE2, instead of having them lock at startup at a blue screen, but I speculate, I'm just very happy they work now. Edited February 9, 2014 by phoenixdownita

[flashjazzcat]

Not sure how to "image" the whole card, any suggestion, like what tool to use?

[ideally I would like to capture all the HW related info as well in case it has to do with some of those fields being misused by the manufacturer, if indeed they are accessed at all during the chain that leads to an ATR successful booting out of a SIDE2 via U1MB SIDEloader]

HxD hex editor is what I use. FDISK will report the make and model of the CF card for you.

 

But logically speaking the fact that if I take the same ATRs and put them in the good CF they work wouldn't rule out inherent ATR related issues and leave us with the crappy CF either being the cause per se or tripping a border case/unexpected/unplanned behavior somewhere on the SW chain?

[i say that because on the crappy CF no ATR that I tried has ever been able to boot, the same ones on the good CF have no issues]

There's been so much ensuing verbiage that - while preoccupied with several different things at once - I may have missed one or two salient points while disseminating all the information. To get down to basics: if ATRs which should have no problems work consistently on one card and not on another, then it's the card - simple as that. There are plenty of cards out there which work reliably with no issues whatsoever; perhaps folks can chime in with their favourite brands.

 

For my own education do you mind explaining the steps that happens during the process from a point of view of information exchange among the pieces?

Just trying to figure out how many SW pieces have to play in concert to make this to work.

If it's considered Intellectual Property then obviously never mind.

The ATA spec (profusely available on the net) explains how any driver interfaces with an IDE device. They all work the same way when reading and writing sectors, and the software implementations on the A8 don't vary all that much at the sharp end of things. Candle's XEX loader (I imagine) is able - since it's doing its own burst reads - to request entire clusters at once (e.g. 8 or 16 sectors). The PBI ROM simply serves up single 512 byte sectors at a time - either to its internal buffer, or to the caller's buffer address. As for the API: the whole thing is documented on my website. The SIDE loader lodges a "mount ATR" request via SIO, the PBI BIOS gets it, opens the ATR, checks the header, sets up tables, and prepares to boot the image on the next restart. If something goes wrong when mounting the ATR, the SIDE loader will receive an error message, which it should act upon (i.e. "Error mouting ATR"), but if all goes well, the next opportunity for problems doesn't arise until the reboot itself, when the PBI BIOS starts feeding virtual sectors from the ATR to the OS bootstrap loader, and then to DOS or whatever is actually loading up. If the ATR is bad, or some transmission errors occur - you'll get a failed boot.

 

Rebooting to a blue screen with absolutely no disk activity whatsoever would indicate some disastrous and immediate transmission error, completely scrambled ATR, or very rapid crash of the boot loader. More commonly, when problems occur, you'll get the familiar "BOOT ERROR" message from the OS.

 

With regard to the good CF only, gut feelings tell me that this is what unblocked TRG flashing ATRs starting up correctly for me now over SIDE2, instead of having them lock at startup at a blue screen...

Most probably. Like I say - if you have what looks like a problem card, try a different one. Edited February 9, 2014 by flashjazzcat

[+phoenixdownita]

First and foremost thanks for the detailed answer.

Second I recognize I'm chasing a slim and narrow corner case out of obsession, so feel free to cut it short at any time, the last thing I want is to piss you off to the detriment of the community at large, I guess this is down to answer "why is this one particular CF misbehaving?" which only makes sense to me because I stumbled on it, were I to buy the good CF first I would never have been interested in walking down this alley.

 

To get down to basics: if ATRs which should have no problems work consistently on one card and not on another, then it's the card - simple as that. There are plenty of cards out there which work reliably with no issues whatsoever; perhaps folks can chime in with their favourite brands.

And that is why I bought a second one that works just fine, just nitpicking before the crappy CF hits the shredder.

 

The ATA spec (profusely available on the net) explains how any driver interfaces with an IDE device. They all work the same way when reading and writing sectors, and the software implementations on the A8 don't vary all that much at the sharp end of things. Candle's XEX loader (I imagine) is able - since it's doing its own burst reads - to request entire clusters at once (e.g. 8 or 16 sectors). The PBI ROM simply serves up single 512 byte sectors at a time - either to its internal buffer, or to the caller's buffer address. As for the API: the whole thing is documented on my website. The SIDE loader lodges a "mount ATR" request via SIO, the PBI BIOS gets it, opens the ATR, checks the header, sets up tables, and prepares to boot the image on the next restart. If something goes wrong when mounting the ATR, the SIDE loader will receive an error message, which it should act upon (i.e. "Error mouting ATR"), but if all goes well, the next opportunity for problems doesn't arise until the reboot itself, when the PBI BIOS starts feeding virtual sectors from the ATR to the OS bootstrap loader, and then to DOS or whatever is actually loading up. If the ATR is bad, or some transmission errors occur - you'll get a failed boot.

I get no "Error mouting ATR" by SIDELoader so the next step is the reboot itself I guess when the CF screws up.

Do you think there's any simple way to attempt to diagnose if the single 512byte read done by PBI can be the culprit?

Not that PBI code is wrong, just the CF doesn't support it very well or doesn't support it according to the std.

I presume that SIDEloader, FAT32Loader and even Windows likely use burst hence the issue may not have surfaced there.

How about the soft drivers? Within the embedded SIDE2 SDX I can format and DIR the contents of the formatted partitions of the non FAT32 (all empty in my case, see below) but it may not use the same access pattern.

 

 

On a different note, when you release the new wave of SDX for SIDE2/U1MB/MyIDE2 etc... will the CAR device also include the new goodies (FDISK4, MATR etc..]? If so would it be possible to use MATR against the FAT32 partition on the CF?

 

The question may seem bizarre to you but as it stands once I boot to the embedded SDX [sIDE2 or U1MB] unless I have a way to mount other ATRs I cannot do much with the created APT partitions. I only possess SIDE2 and so unless I manage to mount the FAT32 or ATRs in it somehow I have no available source to copy files from, I have no SIO2SD/SIO2PC or any other SIO based device I can use as a source/target, and I am not aware of any Windows based app that can allow me to inject data into the non FAT32 portion of the CF (inside the FDISK1 created partitions, like to have FDISK4/MATR available to me).

Edited February 9, 2014 by phoenixdownita

[flashjazzcat]

Second I recognize I'm chasing a slim and narrow corner case out of obsession, so feel free to cut it short at any time, the last thing I want is to piss you off to the detriment of the community at large, I guess this is down to answer "why is this one particular CF misbehaving?" which only makes sense to me because I stumbled on it, were I to buy the good CF first I would never have been interested in walking down this alley.

CF cards have been misbehaving with A8s since time immemorial (although the situation of stability and compatibility became MUCH better overnight when IDE Plus, SIDE2 and MyIDE II came out), and while in the past the thing to do would be to take your MyIDE+Flash cartridge apart and add and subtract components to it until it worked with the media you had attached to it, or load the drivers up with CRC-checks or some such and watch the bandwidth plummet as each sector took three or four goes to transmit properly, nowadays the thing to do is buy a different card, because the hardware - by and large - is just fine. SIDE2 is a lot less fussy about CF cards than SIDE1 (not that SIDE1 was terribly fussy), but I still have a few old (low capacity) CF cards here which won't work for shit with anything. The thing to do with these cards is put them in your SLR camera, or just put them in a drawer and quietly walk away when they're not looking.

 

And that is why I bought a second one that works just fine, just nitpicking before the crappy CF hits the shredder.

Not nitpicking: you're just curious why some cards work and some don't. It would take someone like Hias or Candle with a logic analyser and a lot of spare time to provide a diagnostic report of exactly why said CF card isn't working properly. And even armed with detailed technical data, the card would continue to not work. So I would honestly just use a different one.

 

I get no "Error mouting ATR" by SIDELoader so the next step is the reboot itself I guess when the CF screws up.

Do you think there's any simple way to attempt to diagnose if the single 512byte read done by PBI can be the culprit?

Not that PBI code is wrong, just the CF doesn't support it very well or doesn't support it according to the std.

I presume that SIDEloader, FAT32Loader and even Windows likely use burst hence the issue may not have surfaced there.

How about the soft drivers? Within the embedded SIDE2 SDX I can format and DIR the contents of the formatted partitions of the non FAT32 (all empty in my case, see below) but it may not use the same access pattern.

As I say: it would take someone with more electronic knowledge and testing equipment than I to understand exactly what's going on. Transmission errors have nothing to do with the CF card not adhering to the ATA standard, I'd suggest. It's just missed/doubled up reads of the IDE data buffer. As I say: once upon a time, copious efforts were required to combat such problems via software, but when one out of a hundred or two hundred cards doesn't work, we don't change the software: we use a CF card which does not exhibit problems.

 

On a different note, when you release the new wave of SDX for SIDE2/U1MB/MyIDE2 etc... will the CAR device also include the new goodies (FDISK4, MATR etc..]? If so would it be possible to use MATR against the FAT32 partition on the CF?

Yes and yes.

 

The question may seem bizarre to you but as it stands once I boot to the embedded SDX [sIDE2 or U1MB] unless I have a way to mount other ATRs I cannot do much with the created APT partitions. I only possess SIDE2 and so unless I manage to mount the FAT32 or ATRs in it somehow I have no available source to copy files from, I have no SIO2SD/SIO2PC or any other SIO based device I can use as a source/target, and I am not aware of any Windows based app that can allow me to inject data into the non FAT32 portion of the CF (inside the FDISK1 created partitions, like to have FDISK4/MATR available to me).

Understood. ATRs are invaluable for this purpose, as is KMK's FATFS.SYS driver. It's becoming very simple indeed to move data back and forth between the Atari and the PC using these facilities. But as I understand it, you have a fully functioning CF card which allows you to mount, read, and write to ATRs, do you not?

 

BTW: Did anyone try this yet?

 

Can someone test this, since it appears two independent examples may be insufficient: install SpartaDOS 3.x on a bootable DD hard disk partition (SIDE hardware enabled, with button), disable SpartaDOS X via the Ultimate menu, save settings, power off the computer, then power on again.

 

Use PBI ROM from this post: http://atariage.com/forums/topic/210754-apt-hard-disk-preparation-and-utilities/page-13?do=findComment&comment=2922287

Edited February 9, 2014 by flashjazzcat

[flashjazzcat]

To end the day on a high note: every problematic ATR which ProWizard sent me now works.