drac030

June 4, 2008

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.

June 4, 2008

I don't like MyDos,I want to use SpartaDos. (...) Anyone have an idea how I can re-format the MyDos HD with SpartaDos?

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.

The BIOS ROM is a 27C64 and I don't have an extra one. Can I burn the BIOS upgrade into 27C128A and use that?

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.

June 4, 2008

But it is still called an alpha-release. no beta, no final ... still no own homepage (except from the screenshots, far away from the download-section) ...
The homepage should appear at atari8.info

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

June 4, 2008

What we really need is a DOS that just works for 64K and better machines, and has 90%+ of it's code sitting under the OS. In that case, having FAT support could be done with much less concern for the extra couple of K RAM for buffering that it might need.

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.

June 4, 2008

But the black box, as a device, is far superior in that you press a button (on the black box) at any time, and instantly, whatever application you are using is frozen (...)

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.

May 30, 2008

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.

May 30, 2008

Somebody wrote, that the beta-source will be released, but that was years ago. Since then, there seems to be no life-sign from TRS.

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.

May 30, 2008

The point is that depending on how "sector splitting" is implemented, and other characteristics of the code/device that actually does the drive negotiation/data exchange, you can have a huge difference in performance.

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 black box handles all of this in software on the "atari end" and depending on factors that may influence the nature of the code due to the black box's disk/partition/device management system (which is by far the best and most powerful/advanced on any atari hardisk setup,) there may be even more reasons for "performance hits" which personally, I don't notice, and consider a damn good tradeoff for the functionality it has.

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).

May 30, 2008

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

May 29, 2008

If you look at the IDE standard, the drive (or other IDE device) contains about 99% of the "interface".

This is why we call the Atari-side interface a host adapter. The part that resides on the disk itself is the controller.

It will just about "go straight on" to any 8/16 bit data bus with a bare minimum of necessary logic. (hence the simplicity of the MyIDE hardware spec.)

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.

The speed figures you get with an IDE interface are going to vary widely based on the speed of the device, itself.

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.

For instance, on a sector read, the firmware must decide whether any given 256 byte "ATARI sector" is a "first half" or "second half" of it's corresponding 512 byte "physical sector" on the drive. If its a "first half" then it simply reads the first 256 bytes and stops.

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.

As I said, I havent seen the firmware/handler code of either device. Some or all of this may be totally unapplicable to either or both devices.

So, what's the point?

May 28, 2008

How do you get the 64 and 80 col modes in SDX? I know about the XEP80 driver.

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

May 27, 2008

Well,
at the moment there are just two (2!) programs that make use of separate Antic/CPU access: 1) Video Blitz by Helvetica Bold (a 130 XE demo, there is also a newer version available without sep. Antic access by TeBe) and 2) The Wedge by Ed Bachmann (a sort of file-management program for Sparta-DOS only)..

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).

May 27, 2008

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

May 26, 2008

As far ast the KMK goes.. Thats a decent hardisk controller.. But it doesnt hold a candle to the black-box...

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).

May 23, 2008

You have 2 choices..

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.

April 25, 2008

OK. This time the picture and the colours fit .

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.

April 25, 2008

I still stand by my opinion that they would have been 1000x better off using that and the 2K self-test ROM's area to incorporate a built in DOS.

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.

April 25, 2008

btw time to vomit pals

Have something that is not violet and brown?

April 25, 2008

I'm considering writing a patch for the XL OS that uses some of the $C000-$C3FF area. Is there any interest in my doing this?

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).

April 25, 2008

The RS232 driver, which is loaded from the device (the "R:" handler) is also relocatable.

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.

April 25, 2008

...
A little clunky, and an operating-system routine could help things a lot (does the Atari have any such thing?) but being able to relocate code to arbitrary addresses would have been very nice.

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".

April 25, 2008

As others have indicated, this version as well as one by Charles Marslett (MyDos) was included in several later replacement OS.

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

April 23, 2008

I am using SpartaDos X with its RS232 handler which I belive is used exactly like Atari's 850 handler.

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).

April 18, 2008

was checking out SpartaDOS X 4.41 last night in the emulator and I really like it. Nice work to all involved! I don't know if I want to install it internally yet.

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.