drac030

True, it then is reading smoothly, but buffering a track adds one-two rotations (more often two than one, I would guess), when the track is getting buffered. Thus I am not sure what the final gains are measured in absolute time.

I doubt if there is even an established "correct" interleave for 128 kbps. Especially that there is no universal correct interleave for a baudrate, because this also depends on the disk drive's rotation speed, efficiency of the firmware etc. In any case the correct question is not "what is the baudrate" but "in how many rotations a track is being read". It is 13 rotations for 1050 in ED, and 7 rotations for an US Doubler in same density (but with fast sector skew).

You sure of this? SDX almost never uses the CIO channels, and certainly not for DIR, so it is beyond me how leaving a IOCB open may cause error 129 in DIR...

They are not theoretical, the speedup is real, for instance, with UltraSpeed, the disk drive becomes about twice as fast, BUT you also have to format your floppy with the fast interleave (aka turbo sector skew). If a floppy disk is formatted to the standard interleave, improving the baud rate does not speedup anything indeed. Worse even, using standard baudrate with fast interleave makes the thing even slower than standard. The simplest thing to do seems to be to use the double density image.

To convert a file from DOS 2.5 ED floppy to SDFS, it is enough to just copy it. SpartaDOS reads the entire diskette without a problem. But in the other direction, a DOS 2.5 ED disk is seen as a single density 90k DOS 2.0 media. Therefore you can write files up to the point where the DOS 2.0 707 free sectors are exhausted. This is what these words: "It supports the extended sectors of DOS 2.5 for read only" mean - the "extended sectors" are sectors 721-1023 of a DOS 2.5 ED diskette. And that is what OP was trying to do: copy a 100+ KB file to a DOS 2.5 ED disk. It won't work, because the write limit here is 707 sectors.

A reason may be that SpartaDOS does handle the ED - just not in DOS 2.5 format. And once you switch to the SpartaDOS format, you probably hardly ever need to create new DOS 2.5 ED disks (like OP: once in 35 years).

Speaking of Atari BASIC Compiler[1], if anyone is interested, here is a version which is not tied to D1: (it is satisfied with the default drive) and does not require the original disk in D1 either. Tested it roughly under SpartaDOS X, seems to work. ABC105P.ARC [1] BITD one of my colleagues, who was trying to analyse ABC's output, used to call it "Atari BASIC Complicator".

The ATARIDOS.SYS driver has never supported the DOS 2.5 enhanced density. Quoting the manual: It has been so since ICD times, and nobody cared to add the write support.

I am not asking nor I am explaining. I am guessing. I am not a hardware guy, I am a coder. If I wrote that "0-4 Volts" 18 years ago, it is certain that I did not invent that myself, but that I used some source. I cannot find that source now, but I think I can see the logic behind it.

In standard XL/XE OS this routine is located at $C4DA.

If the TTL levels are around 0-1 V for "low" and 3-5 V for "high", then the article's 0-4 V must be just this after averaginig and rounding. I will add the info about TTL.

Strange indeed, because the OS does initialize PIA in the same loop.

From the history log: http://atariki.krap.pl/index.php?title=POKEY&diff=6521&oldid=6520 it seems that it was me who wrote that, 18 years ago. Honestly, I do not remember where I got it from - I cannot locate it in the most obvious source, i.e. W. Zientara's "Mapa pamięci Atari XL/XE". It should probably say "5V"?

I presume that the "inertia" you are talking about is the Mad-Team mod-player, Inertia 4.5. It could work, it seems that the only thing that prevents it from that is its lame banked RAM test routine, which is destructive for the said RAM contents In fact, one could still run it on Antonia, provided that someone has SDX configured using the specialized 65C816 modules, which I have here, and you do not, because they have not been officially published yet.

AI = Automated Incompetence.

In afterthought: ECHO THAT >>>FILE.TXT is the same as ECHO THAT >>\FILE.TXT i.e. the write should be done to a file named FILE.TXT and located in the main directory of the current drive. Just tried and this works so here. This leaves >>>> for the append mode, which perhaps will be available in the upcoming release. As about APPEND.COM: the Command Processor has evolved a bit since its appearance, so, if C:\BIN\ is to be added to PATH, then SET PATH=$PATH$;C:\BIN\ should work too.

I was just testing what I had at hand then.

No, it does not. But it can be done if needed.

That list has an English version: http://drac030.krap.pl/en-kompatybilnosc.php And it lists the whole lot of 9 programs which use illegal opcodes.

Ok, here it is: fdisk_bug.zip 1) 00000000.MBR - MBR prior to being screwed. 2) 000E003F.APT - the APT partition table apparently causing the issue. The numbers in both filenames are LBA sector numbers (as you can guess). 3) fdisk_16_partitions.png - a snapshot of FDISK partition list prior to the trouble. 4) fdisk_after.png - a snapshort of Eddy presenting the contents of the first half of sector 0 (i.e. the MBR) afterwards. The other half is not visible, but it contains all zeros anyways. 5) mbrview - a small tool I put up today to list the MBR entries in human readable form. Observations: a) To trigger the issue it is enough to open the partition list in FDISK, then write the partition table out, without touching anything. b) but otherwise, when changing settings, any required operations on the APT itself seem to be performed correctly, and APT itself does not seem damaged in any way. c) the only victim is the MBR, which gets overwritten with garbage, being actually some form of APT header in its first 16 bytes, and all zeros besides. d) the red line on the snapshot is the header field "Previous sector in the sector chain" and it points to the actual APT sector, which seems rather odd. I am not sure if the MBR here is 100% correct, because I have restored it manually. It works, though. PS. I looked at the code and you are right, the logical sectors are not packed, I must have confused that with the older version (i.e. KMK/JŻ IDE), where there were 2 logical sectors stored per one physical.

Hmm. Are you sure of this? This is the partition table from my Altirra setup. The entry with red underscores is the partition I created (or rather: tried to create) yesterday: Status $42 means "metadata sector present, 256 bytes per logical sector". And the size field, which per specification should contain "Sector count (number of physical sectors occupied by partition)", has a value of $0000FFFF = 65535 "physical" sectors, i.e. 512-byters = 32 MB. Am I missing something? By the way, this is the exact partiton table FDISK 4.85 keeps destroying. This looks like a bug.

Then there is probably something wrong with your copy of MyDOS. At least I would guess so. 139 is "unrecognized SIO command", and I saw under Altirra's debugger that MyDOS sends these commands: S, N, O, P. Out of these, "O" is not supported (it cannot be, because HDD partitions are not resizable), but MyDOS 4.55 ignores the status in this one case and proceeds. I think I remember MyDOS 4.50 behaving the same way. Downgrading or upgrading the BIOS will not do anything in this respect, because this is not a bug, it has always worked so, even in the days of KMK/JŻ IDE. I do not have a CF card in my real interface, I use spinning-platter HDD. Also, having experienced adventures yesterday with adding one more partition under FDISK 4.85, I am of course quite a bit reluctant to do the same on my HDD. Also, there is not a real point: Altirra emulation is rather good, it usually behaves 100% realistically (maybe except for the I/O speed, but that is a nuance). BTW. I think "65535" in FDISK may mean 65535 "real" sectors, 512-bytes each. To setup a 256-byte partition it is probably enough to enter 32767, which indeed translates to 65534/256. I am not sure about it, though.

There was a bug in it, but it seems to have been fixed ~3 years ago.

I have created a new VHD image under the emulator, used FDISK to create one partition on it, 65535 sectors, 256 bytes per sector. Booted MyDOS 4.55 from an ATR. Choose "O" in the menu. "Drive number or Return?" 3. "Remove drive?" N. "Is drive configurable?" Y. "High capacity drive?" Y. "Drive size (in sectors)?" 65535. Choose "I": Choose "3": Success, no problems whatsoever.

SDX format command can only create SpartaDOS file systems for HDD partitions. It can create a MyDOS disk, but in a very limited way: floppies only, and SD and DD only (90k and 180k). On my dsk I have no partitions which can be formatted in MyDOS format (all 512 bytes per sector, so Sparta only). I remember though that I was several times able to boot MyDOS from an ATR image (on my IDE+, that is), then format another image using MyDOS menu. The command sequence was: O first, then I, and disk number with /N. I do not remember if the space was needed. I tried to do that with an emulated IDE+ under Altirra, but when I wanted to add a 256-byte-per-sector partition there, the FDISK (v.4.85) unexpectedly has deleted the entire partition table. So I will now have to re-reate that somehow before proceeding...