drac030

Maybe they think that nobody cares. If you do, tell them. If "that's not your suggestion", then I don't know what you're talking about. You wanted a "life sign", so what's a better method of invoking the desired life sign than mailing the author(s) of the program in question? That is called feedback, you know.

And what is the exact problem? It should work with SpartaDOS (3.2 I presume) without problems. You should boot the SpartaDOS from floppy, build directories on the partitions (KMK/JŻ doesn't support the FORMAT command, the formatter must be able to just write directories, you may use the FORMAT command from the WEDGE extension to SpartaDOS), and copy stuff. I remember that some version of SpartaDOS 3.2 (it was g or gx, one of these two) had problems when booted from the hard drive. It had something in common with the location of buffers, but I don't remember correctly. I strongly recommend SpartaDOS X 4.4 anyway, it is far superior to 3.2, 3.3 and such. Better use EXACTLY the same (type of) EPROM as it is used in the interface. The parts are carefully selected to avoid timing problems. So, if you want to replace the BIOS, get the interface's EPROM, read its contents, save in a backup file, then burn new one in the same chip. Or request a replacement from the reseller.

Well, tell them this! I am sure the TRS would appreciate your feedback and it could stimulate them to setup the home page etc.

This is exactly SpartaDOS X, except that SDX is yet better. Namely, on 64K machines it may sit under the OS, but on a 128K+ machines it can keep its code and buffers in the extended RAM. So that your concern about buffers occupying the main RAM doesn't really apply. @carmel_andrews: to 32 MB actually. And the filesystem format has been extended so that it can theoretically go up to 4 GB. But this has not yet been implemented. In MyDOS the 16 MB barrier is unbreakable.

I never doubted that a multifunction interface is not really comparable to just a harddisk interface (see my post above). That's why I am comparing only the harddisk-related parts of the BB and KMK/JŻ - and, by the way, that's exactly the topic of this thread ("hard drives", not "freezers" ) If the BB could be switched out of the 256-sector emulation mode into 512-byte sector I/O, then, as Larry wrote above, it would be interesting to see how does it perform under DOS in comparison with the KMK/JŻ IDE. Of course, the only DOS that can do it is the SpartaDOS X 4.4x.

Thanks, Mathy. I have read the file, and it seems to me that the BB partition scheme is superior to the KMK/JŻ/IDEa partition scheme in only one point: namely, in the latter, the logical drive numbers are automatically assigned to partitions in sequential order and you cannot change them other way than changing the order of entries in the partition list (i.e. the physical partition 0 is always mapped to D1:, 1 to D2: and so on). But the version 2.0 if the firmware has this feature implemented. Also, I can't find any information about the maximum number of partitions in the BB. Judging from the partition table size (7 sectors) it is probably greater than in KMK/JŻ (where the limit is 16 partitions). 64 MB in BB is 262144 sectors, 256 bytes each. I can see no information, though, on how to address sectors no. >65535 at the SIO level.

And what "life sign" do you expect? The Desktop has been written and released (in binary form), it works, and the decision whether to release the source is up to the authors.

You mean, basically, that better firmware = better I/O performance. That's what I am glad to agree (since KMK/JŻ is the fastest one and this is me who wrote the firmware ). I admit however, that the interface has some basic hardware support that, in conjunction with the software, speeds up reads in the 256-byte-per-sector mode (it is useless in the 512-byte-per-sector mode, though, and in this the I/O is very fast - in Atari terms - too) The first thing that comes to mind is, that, at the stage of designing the software, you project the other factors, such as the partition table format or "sector splitting", in such a way that these would cause minimal tradeoffs, if any. At least, the partition table is internal to the interface, so you can design it as convenient for your code. The way the firmware does sector splitting is internal to the firmware too, so there are no impediments resulting from the necessity of implementing some established standard. As for the partition table scheme in the BlackBox, what advantages it has over the partition management in KMK/JŻ/IDEa? @Larry: yes, I am curious about it too. And, since Mathy mentioned that BlackBox can create partitions up to 64 MB (in KMK/JŻ/IDEa this limit is 8 GB, btw.), I wonder how such a partition is addressed? Specifically, is it a 65535 sectors 1024 bytes each, or 131072 sectors 512 bytes each, or 262144 sectors, 256 bytes each? In the latter two cases, the sector number is >= 16 bit, so I am curious, how a DOS can address this via DCB (where only 16 bits is reserved for the sector number).

A FAT 16 driver is planned for a future release of the SpartaDOS X. Don't know, if this year, though.

This is why we call the Atari-side interface a host adapter. The part that resides on the disk itself is the controller. Except that interfacing the disks 16-bit bus to Atari's 8-bit bus is not so simple, because e.g. while reading the data there are two reads at the 6502 side (2 bytes), while the disk side should only see one read (1 word). Same for writes. The host adapter must also contain some memory, the controlling register etc. (the PBI logic, in short). MyIDE, obviously, doesn't contain any PBI logic, it also ignores the other half of the IDE bus - hence its simplicity. True. Still the KMK/JŻ/IDEa is the fastest, with any device. During last 13 years (since the KMK/JŻ IDE has been built) I have never seen an IDE device that would have given so slow figures as the BB (I saw 7 KB/s writing speed on some Conner disk - but 20 KB/s reading is low speed, at least under a decent DOS). Some disks were very old, but still. Not true. You always have to read the entire sector. Obviously, you can reset the disk after reading the first half of the 512-byte sector, but this is rather brutal method and despite that, it puts the disk in busy state, it resets the geometry to default (again, with some disks it is a disaster). How long this state lasts, this depends on the device (I saw max. around 30 seconds). Some devices strongly dislike receiving commands when DRQ is on, so even if you gain something this way (which I doubt), you loose on compatibility. So, what's the point?

Maybe by taking a look at the SDX 4.41, 60-page manual addendum: http://trub.atari8.info/sdx_files/4.41/sdx441manual-en.pdf

You forgot Envision. So there are at least three ones. And there are probably few more. Despite that, it is better to have one feature more (i.e. the separate ANTIC/CPU addressing), than more memory. More than 320k is not really required for anything, and big ramdisks are rather funny idea since there are hard drive controllers available. Same with battery backed RAM, from a hard drive you can reload the entire memory in less than 5 seconds, so ... As about the desktops, the TRS Desktop is the only one I saw that actually works. The rest, if they're finished at all, are less or more crap (slow, unstable, and ugly). Diamond GOS has crashed after I played a while, but this might have been the fault of badly "updated" ROM image (it was a flashcart version homemade by someone, and apparently not working well, so I cannot judge).

http://atariki.krap.pl/index.php/BlackBox EDIT: there are also the speed figures there I forgot about (section 3). Normally, the KMK/JŻ/IDEa is at least twice as fast as BB. And with 512-byte sectors (under SpartaDOS X >= 4.40) it is three times faster reading and seven times faster writing

Probably, but the BB is not a hard disk interface - it is a multifunction interface, which can handle hard disk among other things. KMK/JŻ/IDEa is an ATA host adapter only. In turn, it costs a fraction of the BlackBox' price, and is also, as Larry said, very fast in comparison to other storage devices for Atari (although I have no clue about BB speed figures).

Three, actually. There is yet KMK/JZ IDE aka IDEa: http://drac030.krap.pl/en-kmkjz-info.php There are (at least two) people producing it all the time.

Maybe, but as it can be observed e.g. on the Forever party, almost every C-64 picture (not to mention every thing they call "plasma") displayed on the big screen, is either violet, or brown, or both. As if the C-64 palette of 16 colors consisted of 7 violets, 7 browns, black and white :> Pretty boring in longer terms, thus my question.

I think that a built-in DOS, probably (due to limited space) so primitive as DOS 2.5 or worse, would be a disaster and that's good that didn't do that. Now there's at least some real choice.

Have something that is not violet and brown?

I think that writing that as a set of routines an releasing the source would be more useful, actually. I don't see what could you possibly throw off the $C000-$CFFF (except the CHARSET2, perhaps) without loosing much more interesting functionality of the ROM (i.e. the relocatable loader, for example, and PBI routines).

I think it is a bit different thing, because the 850 handler is rather self-relocatable. This is the "poll type 2" protocol. They later wanted to change the protocol, so that the drivers would be in unified, position-independent format, and the computer could load them using the loader contained in ROM. This is how the 1090 drivers were supposed to load into RAM (of course, only these which do not use the PBI "plug and play" mechanism replacing the FP ROM with own one at the time of the initialization and data transfers). The 1090 was later abandoned and this may be why, I think, the entry to the loader is not available in the jump table. But the loader is there, and it is usable, the binary format is even better than that defined later by ICD in SpartaDOS X.

MPDOS for Atari comes with a loader (KDOS) that is relocateable on any page boundary and loader itself is one page. SpartaDOS X defines a relocatable binary format for its utilities, and the binary loader can load the file and fixup it at any byte-boundary. But that's nothing, when we know, that every XL/XE computer contains a relocatable binary loader in ROM. However (and this is the point where it becomes stupid), the loader is not accessible legally. A JMP to it was planned in the jumptable, but it was removed, rumour says, due to "changes requested by marketing".

Installing the Charles Marslett FP routines in ROM makes, IIRC, Turbo BASIC XL 1.5 work incorrectly. To be precise, math functions like LOG, CLOG and raise to power start to fail. It seems then, that Turbo BASIC XL uses some ROM code

Just to clarify that: the SpartaDOS X "RS232.COM" program is not a "handler", it is just a command that loads the proper handler from the 850. By the way, make sure that the RS-232 buffers are outside the banking area ($4000-$7FFF).

Hopefully you will like the next version (currently under development, but not to be released quickly) yet more. BTW. proposals of new features are welcome too in this topic: http://www.atariage.com/forums/index.php?s...t&p=1460486 (not bug reports only). As for installing it internally, it is certainly more convenient, if the intSDX 128 is flashable. That greatly facilitates upgrades.

You could have done that in one step: TYPE CAR:ARCCLOCK.SYS >>ARCCLOCK.SYS