Jump to content
pixelmischief

SpartaDOS X 4.46 and Navigating PicoDOS Image Directories

Recommended Posts

Kyle, just to verify... works great with 4.49b, and errors with C and D, correct?

with and without PBI.SYS?

I didn't try PBI.SYS. I never needed it before.

Share this post


Link to post
Share on other sites

PBI.SYS handles a rare corner case of data needing to be loaded into the shadow RAM underneath the PBI overlay. Nothing about Incognito requires it.

  • Like 1

Share this post


Link to post
Share on other sites

People have lot's of things that aren't 'required', it's good to know what they have or haven't done or tried.. you never know what you will find, or where a fault may lay...

 

bottom line there has to be reason why 4.49b works with the CF drives aka MicroDrives and the other that came after do not...this at least appears to be verified.

 

I have two Seagate ST's, one Apple pull that appears to be a Seagate, a Toshiba that doesn't play nice with a number of devices, and an IBM drive that is probably just one of the other two re-branded (nope it's a re-branded Hitachi, they look damn near identical)... They are mustard/Red labelled(2), White labelled(1), off white black colored, Black and blue, and gradient white to blue respectively. Toshiba was terrible Seagate work fine in all modes, Some Apples do-some don't, IBM was fine... as was the Hitachi... be glad to hear other peoples result... it would appear if it works on both printers and cameras it will work on the Atari, but if it only works in an mp3 player it won't work for our needs

 

The Hitachi id CF+ drive and is also CF I and II

Edited by _The Doctor__

Share this post


Link to post
Share on other sites

The Microdrive Kyle sent me worked just fine with 4.49c if I changed the driver to suit its peculiar 8-bit PIO mode behaviour. It seems completely illogical to me to hold DOS accountable for reliability issues with block IO devices which DOS addresses in a completely hardware abstracted manner. SDX does not know whether the attached storage device is a Microdrive, CF card, SD/CF adapter, spinning hard disk, or what. It would make far more sense to me to look for issues with the drivers, and if SDX 4.49c encounters issues with your hard disk adapter, perhaps this is symptomatic of a generic issue that SDX 4.49c is having with the host adapter in use.

Edited by flashjazzcat

Share this post


Link to post
Share on other sites

This isn't about the singular incompatible microdrive that is of the oem mp3 ilk, this is about the ones that follow the standards...The bulk follow the standards and these are the rule, not the exception to the rule...look to the photography forums and you will find Seagate also made an OEM microdrive for whatever and the firmware is not compatible. Please don't write off everything because they made a special drive for some manufacturer, they weren't meant for this application and it is a known issue.

 

Please don't write off I/O Data, Acard, MyIDE and Incognito as being at fault even though they all work with 4.49b but not c or d? Do we want to fix it or just blame the devices, adapters, etc....

Maybe it's all four of My MIO's fault or perhaps it's the Black Box... or maybe it's just Joe and Kyle's incognitos.... while we are at it maybe it's both cords.. I find it a little suspect that all configurations work with 4.4b but not c or d but surely nothing about DOS has anything to do with it... it couldn't have anything to do with timing or how it interacts or anything of that nature. Kyle is correct the error occurs with or without PBI.SYS loaded....

 

If we change something and a simple adaptec 5500 quits working, lets not fix or find out what has gone wrong or what the issue is, let's just ditch the adaptec controllers as it's clearly now it's at fault, we should stop using those kinds of hard drive/adapter combinations as well... although I don't think DOS know everything or much of anything about the devices individually.

 

Nothing to see here again folks, move along...

Share this post


Link to post
Share on other sites

PBI.SYS is irrelevant here for the reasons I already described. I'm perfectly open to the idea of an ATA driver having an issue with a Microdrive, but I've also explained why the issue is unlikely to be caused by DOS.

Share this post


Link to post
Share on other sites

Something changed...... DOS before C works - DOS after C doesn't... clearly something in the package has changed.... I have spent a great deal of time hooking up various combinations of all this crap. The only thing that cures the issue is to roll back to 4.49b.... so maybe all the other fixes done to C and D could be applied one at a time to B till B breaks then we will know why... or at least have a clue as to what caused the previously non issue to become and issue.

 

Kind of been through this before and it inevitably turns out something gets found or fixed especially when others start chiming in...

Share this post


Link to post
Share on other sites

Have you reported this to DLT then? Kyle suggested doing so but I thought it unwise until he tells me if the Incognito BIOS I sent him works with 4.49c when using Microdrives. Of course I'm not involved with SDX development but since the reported device done error is generated by my driver and not by DOS, I'd like to know what's going on.

Share this post


Link to post
Share on other sites

if it were the bios It would probably error no matter what DOS was in use unless it were on the bleeding edge of a time critical function or the interplay between the two..

since it did work, and then did not, unless both updates or upgrades happened at near the same time... a roll back to the previous bios would have made it go away... or the previous DOS as was the case.

 

I am certain no matter what the case is, you more than likely improved the BIOS or scrutinized it in such depth that it's benefited from the exercise.

 

Looks like Sparta will possibly need or get the same treatment.

 

abcdefg. Sparta is the one for me... it's all beta :) major typo? or .... slip of the finger on the keyboard...

actually it looks like the archive does not contain 4.49b either... I think the spartados x site is slightly behind..

 

Sometimes I think it all becomes a game of whack-a-mole...

thanks for all your efforts, It all gets worked out in the end...

Edited by _The Doctor__

Share this post


Link to post
Share on other sites

if it were the bios It would probably error no matter what DOS was in use unless it were on the bleeding edge of a time critical function or the interplay between the two..

since it did work, and then did not, unless both updates or upgrades happened at near the same time... a roll back to the previous bios would have made it go away... or the previous DOS as was the case.

As far as I can tell, Kyle applied the Incognito BIOS update I sent him while simultaneously rolling back from 4.49c to 4.49b, and since 4.49b worked anyway, I'm none the wiser until I hear whether 4.49c works for him with the newer BIOS.

 

The observation that a BIOS issue would exhibit itself regardless of the DOS in use is of course correct, but this is because - as I've said all along - the Device Done error emanates from the driver, not from from the file management system. Let's look at the possible causes of error 0x90:

  • Device times out after an ATA command is issued
  • Device doesn't return SKC,RDY and DRQ after an ATA command is issued
  • DRQ remains high after the last byte of the sector buffer is transferred (indicating one or more skipped reads)

The first issue could be caused by higher than envisaged seek latency. The other two are caused by instability, drive faults, etc. At no time in two years of using 4.49c have I encountered a Device Done error which wasn't related to a driver issue or - more typically - the usual bus capacitance/timing issues of the chosen media. DOS is the last thing I would suspect as the cause of the issue, so if it can be demonstrated that SDX 4.49c is capable of returning specious Device Done errors, I will be fascinated to see evidence of it. :)

Edited by flashjazzcat
  • Like 2

Share this post


Link to post
Share on other sites

Looks like Sparta will possibly need or get the same treatment.

 

As FJC points out, SDX does not handle PBI devices itself, it just calls routines of the driver. The only situation when 'Device Done' is reported is related to serial communications. So it is natural to look for the problems not in the DOS, but elsewhere.

 

However, if you are able to do more tests, you may bypass DOS driver either with MAP (e.g. MAP 1 OS), or completely (DEVICE SIO /A), and see what happens.

You may even load the old 4.22 driver (DEVICE SIO /C).

  • Like 3

Share this post


Link to post
Share on other sites

I'll try it later today. I'm using DEVICE SIO /A BTW. Does this even matter when talking to a PBI device?

Share this post


Link to post
Share on other sites

I'll try it later today. I'm using DEVICE SIO /A BTW. Does this even matter when talking to a PBI device?

 

The only advantage to /A here is reducing the system footprint (since I assume most or all of the SIO.SYS driver is jettisoned). Since the Incognito PBI driver already contains an SIO handler, this - when activated - will always take precedence over the Sparta SIO driver, even when /A is omitted. This isn't the same as the high-speed patched OS, for example, since the OS serial IO handler is subordinate to the SpartaDOS SIO driver. PBI handlers are at the top of the tree, though, so in your case it makes no difference whether the switch is present or not.

  • Like 1

Share this post


Link to post
Share on other sites

I guess it was a false alarm. The error WAS real, _The_Doctor__ saw it as well as I did. Whatever caused it, it's gone now. Everything seems to be good now, except holding OPTION now does not bypass the SDX startup files. This is a bit of a nuisance because my AUTOEXEC.BAT has a COLD /N in it to auto-boot Sparta 3.2 for the BBS.

 

Edit: It was NOT a false alarm. The ERROR - 144 came back after a while. Uggg... Back to 4.49b.

Edited by Kyle22

Share this post


Link to post
Share on other sites

I'm not sure what kind of software issue would take time to reappear in this manner. More detail about the exact circumstances in which the problem occurs would be helpful. What's in CONFIG.SYS, what drivers are present, which OS is in use, the disk/partition geometry, partition sector size, etc, etc. If you just revert back to 4.49b hoping the issue will miraculously disappear in a subsequent revision, we may never figure out what's going on and as a result the issue may never be fixed.

  • Like 2

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...