trub

Sure it can be done. However, I think it would be better to patch DPB for drive C (it now set for 90k disk in the second drive, so of questionable use nowadays).

TT simply calls SIOV OS procedure to access the B: drive, so the speed depends on OS. You get high speed if OS itself supports this or if the high speed handler is hooked to the OS vector (such as SIO driver in the FJC's Ultimate1MB firmware). However, after reading the data, TT still needs to send it to Indus CP/M via SIO. A double transfer is then needed: drive B: -> TT -> Indus CP / M, which results in poor performance.

This is planned (I say cautiously that for version 4.60 )

I thnik you should use File -> Save Firmware -> Save Ultimate 1MB Flash. Then select the file as the default firmware for Ultimate.

The extended driver INDUSX.SYS is being developed. It will enable track buffering and will have some additional features. We plan to include it in the SDX Tookit with the next release.

TT uses SIOV to read (write) from D2: when B: is accessed. If you have OS or PBI driver with hi-speed SIO, it is used to get the data. However, TT then transfers the data further to the Indus drive which supports 19200bps by default.

TT supports CP/M drives B: and C:. They are both mapped to Atari D2: drive with 256BPS disk (B:) or 128BPS disk (C:, rarely used). TT works well under SDX, but Indus drive (D1:) should be directly accessible. So, you have to deactivate any hard disk partition mapped to D1: to let the SIO floppy respond. I have also successfully used ATR disk image on IDEPlus as CP/M B: (mapped as D2: with ATRM utility). The speed is still not very impressive, since the protocol requires passing control commands between Indus and TT through SIO.

This version has bugs, you need to upgrade it to 1.20 as they say in the Indus GT Service Manual (pt. 4.14): "If the EPROM in the drive you are working on has a version number of 1.00 or 1.10, then it should be replaced immediately with the latest version of the device. The latest version to date is 1.20."

Which ROM version is displayed by the tool ? Can you hear the bell when the display reaches FF ? Are there any other drives connected ? Note that the drive should be set to D1: (see jumpers at the back).

Here is some information for CP/M newbies. CPMTOOL utility performs two basic actions: 1. Testing the SRAMCharger using different memory configurations. The drive must be operational, since the tests are executed by Z80 CPU at the drive side. In case of an error, its code is displayed ( 1-8 ). See my site for description of the error codes. 2. Restoring the missing parts of sectors 1-3 with the original contents of CP/M code. CP/M double density discs use full capacity of these sectors (unlike Atari discs or ATR files which only hold 128 bytes). So after copying the CP/M disks to e.g. ATRs, upper halves of the sectors 1-3 are lost and must be later restored using this utility. Nezgrar, rdea6, thank you helping me with the links

Note that the physical disks should be then patched with CPMTOOL to restore the missing parts of sectors 1-3.

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

Of course they should be connected. Eagle editor does not show the Vss/Vcc connections for basic TTLs for a reason.

Jerzy Sobola website has been moved to a new location: http://jsobola.atari8.info So the correct link is now: http://jsobola.atari8.info/dereatari/atariepr/indus12.zip

I agree that spaces before the semicolon should be ignored. In fact the same question applies to '-' starting a batch file or '#' for executing EXE programs (with X.COM). So we have to resolve this in the upcoming releases.

The maximum capacity of SDX command line buffer is 64 characters. It seems that you have exceeded this limit (especially shortening the comments may help).

You will have to add the two subdirectories to the path too, i.e. e:\system\apttools e:\system\sptatools. This is the way PATH works (not only on SDX, but also on Windows and Linux).

That is a surprise. Can you check if the 'cheap' model has the same mainboard as the regular one ? Is the front panel connector soldered ? What about ROM version ? It seems to me that there may have been another reason for removing the panel. I don't think that this would cut down the price at lot.

Indus GT 1.20 ROM: http://www.dereatari.republika.pl/atariepr/indus12.zip

Definitely. According to Indus Service Manual: "If the EPROM in the drive you are working on has a version number of 1.00 or 1.10, then it should be replaced immediately with the latest version of the device.". Version 1.10 does not allow you to run CP/M (DRIVE TYPE + ERROR does not work). It also seems to fail executing the commands sent by CPMTool. I will try to investigate this further.

Can you check if this more recent version 0.5 still reports an error ? cpmtool05.zip

At what value does the track counter on the drive stop ?

Z.SYS was introduced in 4.41 afair. All official images, including 4.47, contain it. Type DIR CAR: to check.

Z.SYS driver is included in recent versions of SDX.

It is 30 bytes indeed. The User's Guide mentiones 28 bytes for backward compatibility, however it should be corrected in the next revision. The two bytes at COMTAB+61 (referred as RUNLOC) were used by SpartaDos 3.x to store the run address of an executable started from the command processor. This has been dropped in SpartaDOS X, so the COMFNAM is now two bytes larger and joins LBUF (as stated in Programming Manual).