Indus Ramcharger Help

[JR>]

I have been thinking and believe I have found what is wrong. A bit of background first.

All atari 8 DD drives that I know of Will only send/receive 128 bytes of data for sectors 1, 2 and 3. this so the OS can read the boot strap routine stored on the drive to boot dos etc because the disk boot routine was written only with 128 byte segments in mind. Once the boot strap is loaded, it takes over and continues to load dos using 256 byte segments. The drive itself will write the 256 bytes for sectors 1 -3 with the 2nd 128 bytes padded out with what ever is in memory of the drive.

I believe that CP/M disks are 256 byte right from sector 1 so 384 bytes of information is missing from the ATR files. ATR files I believe are setup in the same way with no space in the atr file what so ever for the extra data at all. What you will need to do is to get a disk from another source or an image file that can be written with a 360K mech connected to the pc. Maybe someone with an ATR8000 cpm disk could help you out.

By the way, What does the Super sincromesh disk do?

 

James

 

 

Yeah, that's what I was alluding to when I refered to missing CP/M info. I'm not sure we will ever find another source for those disks. I sent an email the the Retrobits webmaster to see if he has the original disk that the images were made from.

 

I do have an ATR8000 with CP/M disks, but I don't think there is any chance of that working. The boot sectors for all CP/M disks are completely machine dependant.

[EDIT] Oh you were suggesting using the ATR8000 to copy the disks, not use the ATR8000 disks in the INDUS, yes that might work.[/EDIT]

 

Yes Carsten is correct. As I understand it, the Indus drives had HiSpeed code that they named "Syncromesh" in the BIOS, but it is buggy and does not work. They then released a version of DOSXL that included working syncromesh code that can be loaded into the RAM in the drive to regain the high speed funcionality. I think Super Syncromesh is an even later version that is supposed to be even faster than the original.

 

The only problem is that it's a major PITA. It takes about 3 floppy disks and a bunch of copying and configuring to make a working syncro disk from the master. Then once you have that, it takes forever to load the code into the drive and it sits there and polls all eight drives until they timeout, which takes even more time. Once you finally get it loaded, it stays there until you turn off the drive though.

 

I understand there is also a driver in SpartaDos X that loads Hispeed code into the INDUS, but I've never tried it. That might be a faster solution.

 

Once loaded though, the drive really is fast. I think I read somewhere that it is even faster than a Happy. I think I also read somewhere that it pushes the limits of SIO so far that there are often SIO transmission errors that can cause so many retries that the speed improvements are lost, although I've never experienced that.

 

What I'd really like to see is a new BIOS for the INDUS that replaces the buggy code with a working version of syncromesh. Anybody feel ambitious?

Edited September 25, 2007 by JR>

[sup8pdct]

I do have an ATR8000 with CP/M disks, but I don't think there is any chance of that working. The boot sectors for all CP/M disks are completely machine dependant.

[EDIT] Oh you were suggesting using the ATR8000 to copy the disks, not use the ATR8000 disks in the INDUS, yes that might work.[/EDIT]

 

Yes Carsten is correct. As I understand it, the Indus drives had HiSpeed code that they named "Syncromesh" in the BIOS, but it is buggy and does not work. They then released a version of DOSXL that included working syncromesh code that can be loaded into the RAM in the drive to regain the high speed funcionality. I think Super Syncromesh is an even later version that is supposed to be even faster than the original.

 

The only problem is that it's a major PITA. It takes about 3 floppy disks and a bunch of copying and configuring to make a working syncro disk from the master. Then once you have that, it takes forever to load the code into the drive and it sits there and polls all eight drives until they timeout, which takes even more time. Once you finally get it loaded, it stays there until you turn off the drive though.

 

I understand there is also a driver in SpartaDos X that loads Hispeed code into the INDUS, but I've never tried it. That might be a faster solution.

 

Once loaded though, the drive really is fast. I think I read somewhere that it is even faster than a Happy. I think I also read somewhere that it pushes the limits of SIO so far that there are often SIO transmission errors that can cause so many retries that the speed improvements are lost, although I've never experienced that.

 

What I'd really like to see is a new BIOS for the INDUS that replaces the buggy code with a working version of syncromesh. Anybody feel ambitious?

 

I never would have thought that CP/M would have machine specific boot code in them.

I am very well aware of syncromesh and have used MY indus with sparta dos X. just wondering what the super part was.

I have pulled apart how the syncromesh works from the atari point of view. it is a lot like the XF551 high speed except the baud rate used for the sector data is at least twice the speed of the xf and about 1.4 times faster then the USD type.

For those who don't know. the command frame for both the XF and syncromesh indus is sent at the normal speed but the command byte has it's highest bit set. The data frame is then sent/ received at the high baud rate. unlike the USD type where both the command and data are sent at high speed.

Isn't CP/M written for the 8008 processor? which the Z80 is a copy of and much improved?

 

James

[JR>]

I never would have thought that CP/M would have machine specific boot code in them.

I am very well aware of syncromesh and have used MY indus with sparta dos X. just wondering what the super part was.

I have pulled apart how the syncromesh works from the atari point of view. it is a lot like the XF551 high speed except the baud rate used for the sector data is at least twice the speed of the xf and about 1.4 times faster then the USD type.

For those who don't know. the command frame for both the XF and syncromesh indus is sent at the normal speed but the command byte has it's highest bit set. The data frame is then sent/ received at the high baud rate. unlike the USD type where both the command and data are sent at high speed.

Isn't CP/M written for the 8008 processor? which the Z80 is a copy of and much improved?

 

James

 

Ah, you probably have more experience with it than I do then. I just know that the same site that has the CP/M images also has 2 version of DOSXL images, one with Syncromesh and the other with "Super" Syncromesh, but I really don't know what makes it super .

 

Yes, CP/M mostly ran on 8080 and Z80 CPU's, but the BIOS for most systems resided on the boot disk instead of in ROM and was customized for each hardware platform. Even changes in the configuration of a system required changing the boot code on each disk that you wanted to boot from. The ROM in most CP/M system is just a very simple file loader that first laods the BIOS into memory and passes control to it, which then loads and executes the rest of the CP/M code which was fairly standardized between systems.

[sup8pdct]

Yes, CP/M mostly ran on 8080 and Z80 CPU's, but the BIOS for most systems resided on the boot disk instead of in ROM and was customized for each hardware platform. Even changes in the configuration of a system required changing the boot code on each disk that you wanted to boot from. The ROM in most CP/M system is just a very simple file loader that first laods the BIOS into memory and passes control to it, which then loads and executes the rest of the CP/M code which was fairly standardized between systems.

 

That makes things hard then. If the bios is the first thing loaded, then again getting as far as the CP/m welcome message could mean that bios is built into the terminal screen? or the rom? wishfull thinking...

 

James

[sup8pdct]

I do have an ATR8000 with CP/M disks, but I don't think there is any chance of that working. The boot sectors for all CP/M disks are completely machine dependant.

[EDIT] Oh you were suggesting using the ATR8000 to copy the disks, not use the ATR8000 disks in the INDUS, yes that might work.[/EDIT]

 

could you possiably copy the atr8000 disks with the pc and send them to me? I have compared cp/m version 2.2 from the indus atr file and some other computer and it appears that they are very much the same except for the missing data. Comparing the atr full with the indus part just may reval what is missing.

Rebuilding it would be a problem.......

 

James

[drac030]

I just know that the same site that has the CP/M images also has 2 version of DOSXL images, one with Syncromesh and the other with "Super" Syncromesh, but I really don't know what makes it super

 

IIRC, the ordinary Synchromesh does 38,4 kbps. The SuperSynchromesh - 68,2 kbps, but it does not work well enough. The INDUS.SYS driver included in the SpartaDOS X appears to be a better version of the SuperSynchromesh, though: it is both fast and stable.

[+Larry]

Yeah, that's what I was alluding to when I refered to missing CP/M info. I'm not sure we will ever find another source for those disks. I sent an email the the Retrobits webmaster to see if he has the original disk that the images were made from.

 

I do have an ATR8000 with CP/M disks, but I don't think there is any chance of that working. The boot sectors for all CP/M disks are completely machine dependant.

[EDIT] Oh you were suggesting using the ATR8000 to copy the disks, not use the ATR8000 disks in the INDUS, yes that might work.[/EDIT]

 

Yes Carsten is correct. As I understand it, the Indus drives had HiSpeed code that they named "Syncromesh" in the BIOS, but it is buggy and does not work. They then released a version of DOSXL that included working syncromesh code that can be loaded into the RAM in the drive to regain the high speed funcionality. I think Super Syncromesh is an even later version that is supposed to be even faster than the original.

 

The only problem is that it's a major PITA. It takes about 3 floppy disks and a bunch of copying and configuring to make a working syncro disk from the master. Then once you have that, it takes forever to load the code into the drive and it sits there and polls all eight drives until they timeout, which takes even more time. Once you finally get it loaded, it stays there until you turn off the drive though.

 

I understand there is also a driver in SpartaDos X that loads Hispeed code into the INDUS, but I've never tried it. That might be a faster solution.

 

Once loaded though, the drive really is fast. I think I read somewhere that it is even faster than a Happy. I think I also read somewhere that it pushes the limits of SIO so far that there are often SIO transmission errors that can cause so many retries that the speed improvements are lost, although I've never experienced that.

 

What I'd really like to see is a new BIOS for the INDUS that replaces the buggy code with a working version of syncromesh. Anybody feel ambitious?

 

 

From an earlier thread I started:

 

>> I thought that it would be interesting to do some benchmarking using several types of floppy drives and sector interleaves. In all cases, I used a 720 sector, SD disk (or image) and sector copied the disk to an APE image. As a baseline, I copied the SD disk at 1X to the APE image. In all other cases, the Black Box high-speed drivers were used.

 

Baseline: Interleave=8 2:35

Arch/Dblr 1050: Interleave=5 1:14

Happy 1050: Interleave=8 1:04 Note: Interleaves of 5 and 6 also produced identical results (track buffer).

Floppy Board: Interleave=2 0:42

Indus with Synchromesh loaded: Interleave=6 1:20 Note: Interleave=5 failed -- missed many sectors until next rotation.

APE - APE: Interleave=n.a. 0:49

 

The most interesting aspect to me was that although I have read that an Indus communicates at 81 kbs, it clearly is slightly slower than the 1050 Doubler. And of course, of the physical SIO drives, the Happy came out on top. <<

 

IF your track buffer can be made to work that should help things. Also, you're very right about the PITA in setting up Synchromesh. The second version is called Super Synchromesh, I believe. But you can set up the disk so that it boots faster. The first three or so tracks have the regular interleave. The rest of the disk is the faster interleave, so the boot is quite a bit quicker. But that means that you have to use Dos XL, so Sparta X is a nicer choice.

 

-Larry

Edited September 26, 2007 by Larry

[drac030]

The most interesting aspect to me was that although I have read that an Indus communicates at 81 kbs

 

Indus SuperSynchromesh and Sparta X fast serial speed equals to value 6 of the Pokey clock divisor. This is 68,2 kbps AFAIK. The ordinary Synchromesh sets the clock divisor to 16, which is 38,4 kbps. US Doubler is 10, IIRC.

[trub]

I believe that CP/M disks are 256 byte right from sector 1 so 384 bytes of information is missing from the ATR files. ATR files I believe are setup in the same way with no space in the atr file what so ever for the extra data at all. What you will need to do is to get a disk from another source or an image file that can be written with a 360K mech connected to the pc. Maybe someone with an ATR8000 cpm disk could help you out.

You are right. I have compared the Retrobit ATR file with other CP/M 2.2 editions and it seems that sectors 2 and 3, which contain a part of CP/M command processor are corrupted (128 of 256 bytes of each sector are lost).

It seems that one can fix this by getting the missing pieces from a CP/M disk for a different platform (many of them are available on the Net), because the command processor is platform-independent (64kb CP/M 2.2 version is appropriate). However, writting the full 256b of sectors 1-3 to a disk can be a question here.

 

For example, this version seems to be compatible (file diska.img is the CP/M image)

Edited September 25, 2007 by trub

[sup8pdct]

I believe that CP/M disks are 256 byte right from sector 1 so 384 bytes of information is missing from the ATR files. ATR files I believe are setup in the same way with no space in the atr file what so ever for the extra data at all. What you will need to do is to get a disk from another source or an image file that can be written with a 360K mech connected to the pc. Maybe someone with an ATR8000 cpm disk could help you out.

You are right. I have compared the Retrobit ATR file with other CP/M 2.2 editions and it seems that sectors 2 and 3, which contain a part of CP/M command processor are corrupted (128 of 256 bytes of each sector are lost).

It seems that one can fix this by getting the missing pieces from a CP/M disk for a different platform (many of them are available on the Net), because the command processor is platform-independent (64kb CP/M 2.2 version is appropriate). However, writting the full 256b of sectors 1-3 to a disk can be a question here.

 

For example, this version seems to be compatible (file diska.img is the CP/M image)

I also found source code for 2.2. the very first bit looks like CP/m itself and not the bios which appears to be last.

been thinking about the 256 byte write sector problem for sectors 1 -3. Maybe, just maybe some modifyed 1050's will accept 256 byte data frames for sectors 1-3 and write them out. only way is to try it and see. you will need to put values in to $300-$30B and jump to $e459. Maybe the Indus can do that as well? if not, then putting an XF551 mech into a pc and using an editor is the only way to go to fix up the disk.

 

james

[+Larry]

The most interesting aspect to me was that although I have read that an Indus communicates at 81 kbs

 

Indus SuperSynchromesh and Sparta X fast serial speed equals to value 6 of the Pokey clock divisor. This is 68,2 kbps AFAIK. The ordinary Synchromesh sets the clock divisor to 16, which is 38,4 kbps. US Doubler is 10, IIRC.

 

Hi Drac030-

 

Thanks for the additional info. My test must have used regular Synchromesh rather than Super Synchromesh. I'll have to go back and verify that I have SS, and re-run the test.

 

Also-

Does anyone know if the Rom version in the drive makes any difference as regards speed? IIRC, Indus/Future Systems released at least 3 different rom versions for the drive.

 

-Larry

Edited September 26, 2007 by Larry

[TXG/MNX]

Where can I find these 3 roms ?

[+Guitarman]

Here are 2 roms I found in my archive of stuff. Don't know the differences though.

 

Indus_Roms.zip

[sup8pdct]

If i Recall correctly, 1 or 2 of the early rom versions had trouble with enhanced density.

Any one with a field service manual will be able to tell ya. I have one but I cannot recall where it is

 

James

[+remowilliams]

Where can I find these 3 roms ?

I've got three different versions in three different drives right here. No way to dump them though.

[+Larry]

I'm trying to re-run my benchmark using a "for-sure" copy of Synchromesh II -- AKA "Super Synchromesh," and need some info -- how do I INIT a disk on the Indus using Dos XL with the fast skew? The default seems to be standard skew. There is a file called "INITSYNC" but appears that it is a booting disk with the first tracks "slow" for booting, then the rest of the tracks in Synchromesh skew. I have looked in the Future Systems manual, but have not found this.

-Larry

[sup8pdct]

I'm trying to re-run my benchmark using a "for-sure" copy of Synchromesh II -- AKA "Super Synchromesh," and need some info -- how do I INIT a disk on the Indus using Dos XL with the fast skew? The default seems to be standard skew. There is a file called "INITSYNC" but appears that it is a booting disk with the first tracks "slow" for booting, then the rest of the tracks in Synchromesh skew. I have looked in the Future Systems manual, but have not found this.

-Larry

I haven't played much at all with syncromesh with dosXL, only with spartaDosX. I have found that Syncromesh is close if not that same as the USD format disk skews and speeds.

As many people know, if a high speed format disk is read at normal sio speeds, loading is much slower till the highspeed routines cut in.

 

As for getting the Indus to format the highspeed sector layout, I think one needs to set the high bit on the command byte for the indus to format that way, after telling the drive via the percom drive control block what density to format in.

Bit of a PITA i know but I haven't played with it for 15 years so memory is a bit scratchy.

 

Bye the way, I just found my scanned schametics for the indus. any one want a copy? is 3 pages.

 

James

[+Larry]

Well, this has proved to be quite interesting. It turns out that the disk being INITialized in the Indus was in Synchromesh skew. I was able to verify that from the manual and the fact that when copying *files* to the Indus, it wrote to the drive at Synchromesh speed. Further, examining the disk after formatting, it has a skew of 4. That is the "fastest" skew that I have encountered except for the floppy board (2). That's the only good news.

 

Now the bad news (a longer list)... Dos XL writes poorly in Synchromesh mode. It writes several sectors, then pauses to catch up and/or retry. With Synchromesh engaged, it will not work at high speed with the Black Box drivers. The "DUPDSK" file from the Dos XL distribution disk also would not work at high speed -- only regular SIO speed. (That was what confused me initially about getting the disk formatted correctly.) Using my SpartaDos X cart, things were a little better. I loaded Synchromesh from the Dos XL boot disk, then re-booted using the SDX cart. Copying files was smoother, but not by a lot. I re-formatted the disk using SDX, and it laid down a skew of 5, so this was an apples-to-oranges comparison.

 

I would still like to try to get this benchmarked -- can anyone recommend a good sector-copier that works with SDX?

 

Methinks that calling Super Synchromesh "quirky" is being overly kind...

 

-Larry

Edited September 27, 2007 by Larry

[drac030]

Using my SpartaDos X cart, things were a little better. I loaded Synchromesh from the Dos XL boot disk, then re-booted using the SDX cart.

 

I recommend you to try the native SDX Synchromesh instead. Power-cycle the drive, boot the SpartaDOS X afresh and then type:

 

INDUS.SYS

 

from the command prompt. Then you should be able to format a floppy with HighSpeed skew in the SpartaDOS X Formatter.

 

But - as for testing speed - the SDX SIO driver tends to disable VBL temporarily for high baudrates, like Indus turbo mode. So if you test the speed using a VBL-based timer, the results may be a bit too good

[+Larry]

Using my SpartaDos X cart, things were a little better. I loaded Synchromesh from the Dos XL boot disk, then re-booted using the SDX cart.

 

I recommend you to try the native SDX Synchromesh instead. Power-cycle the drive, boot the SpartaDOS X afresh and then type:

 

INDUS.SYS

 

from the command prompt. Then you should be able to format a floppy with HighSpeed skew in the SpartaDOS X Formatter.

 

But - as for testing speed - the SDX SIO driver tends to disable VBL temporarily for high baudrates, like Indus turbo mode. So if you test the speed using a VBL-based timer, the results may be a bit too good

 

OK, did that, and several other things...

 

I tried several sector copiers, and none so far work with Sparta. So I thought I'd copy files as a comparison. I copied FROM an APE image TO the Indus (and a 1050 as a baseline.) The results are interesting.

 

Stock 1050 using MyDos 4.50 to copy 10 files, 677 sectors, no verify: 2:20

"Happy" in slow mode write with verify (same files): 2:39

Indus using Dos XL skew=4, using same files and Atari Dos-type format: 1:31 (Impressive! Still some problems missing writes, but very few in this test.)

Indus using SDX with Indus.Sys, skew=4: 4:07 (SDX choked on the skew=4, and ended up with a disk error)

Indus using SDX with Indus.Sys, skew=5, Sparta format: 2:42 (SDX did write in fast mode, but kept returning to track zero to establish its track position)

Happy 1050 using SDX, skew=4: 158

Happy 1050 using MyDos, skew=5: 2:02

 

Note: all copy tests used the same files. Formats were Atari Dos type, except as noted. Skew really doesn't matter with the Happy.

Well, I'm very surprised, but the figures don't lie: the Indus using Dos XL and its Super Synchromesh was the fastest. I take back all my bad thoughts about the Indus...

 

-Larry

[drac030]

Indus using SDX with Indus.Sys, skew=4: 4:07 (SDX choked on the skew=4, and ended up with a disk error)

 

Not surprised. SpartaDOS X, while accessing non-native filesystems, can be rather slow because of the way the disk format is internally translated to the Sparta format and back. Normally it doesn't hurt because when the SpartaDOS X is your main DOS, most of your floppies are in Sparta format anyway...

 

Indus using SDX with Indus.Sys, skew=5, Sparta format: 2:42 (SDX did write in fast mode, but kept returning to track zero to establish its track position)

 

Yes. This is the place where the 3.2 (and further versions, like 3.3 or Real.DOS) are more efficient than X 4.x. When closing a file, it writes out the data sector, then updates the sector 1 (first seek to track 0), then writes out the file map sector, then updates the bitmap (the second seek to track 0). On real floppy, as a result, the head goes to and fro several times when the software closes a file being written to.

 

The real reason for that behaviour is the internal implementation of the buffers, the DOS does not keep separate buffers for the data, maps, bitmap or bootsector, but the buffers are freely assigned to the sectors as they're necessary regardless of the type. As a result, though, when they're flushed out to the media, the order of writing them out is far from being optimal. This of course doesn't matter much on a harddisk ...

[JR>]

could you possiably copy the atr8000 disks with the pc and send them to me? I have compared cp/m version 2.2 from the indus atr file and some other computer and it appears that they are very much the same except for the missing data. Comparing the atr full with the indus part just may reval what is missing.

Rebuilding it would be a problem.......

 

James

 

Are you asking to have physical disks mailed to you? I'd be happy to do that, but postage might not be cheap to Australia. I'm not sure if they would be of much value to you if you don't have an ATR8000.

 

There are images available that you could use to make your own copies. The only problem is they would not be bootable on an ATR8000. All of the files on the copy would be readable, but the boot tracks probably would not. They did something really weird with their disk format on the boot tracks and I've never been able to copy that part of the disk, only write new tracks usnig the ATR8000 CP/M itself.

 

I'm not sure if it was intended to be a form of copy protection, but it certainly works that way. It's some kind of weird combination of single density and double density tracks that is almost impossible to read or write even with very old Single Density capable Floppy controller cards in a PC. I suppose a catweasel could do it, and I've always meant to see if the Happy Discovery Cart could handle it, but I don't have an ST 5.25 drive.

 

Anyway, if you would like me to mail the floppies to you and don't mind paying the postage, I'll do that, or I can send you the images and you can see what you can get from those first if you like.

[JR>]

Bye the way, I just found my scanned schametics for the indus. any one want a copy? is 3 pages.

 

James

 

Yes, I'd like to see that, do you have it in an electronic format?

[JR>]

I got a response from Dan Vernon of the Retrobits Site. He never had the original disks himself, but said that he got the images from Bob Woolley and suggested I contact him. I've sent him a PM so we'll see if he has access to them.

 

I also did a newsgroup search and found some old messages from a couple of people on c.s.a.8bit that said they had the disks. I recognized a couple of the handles....'Roy G Biv' and 'Sage' , but I haven't seen any activity from them in a while. If anyone knows how to contact either of them, they might still have the disks.

 

The search continues........

[sup8pdct]

Bye the way, I just found my scanned schametics for the indus. any one want a copy? is 3 pages.

 

James

 

Yes, I'd like to see that, do you have it in an electronic format?

yes they are.

Page 1 http://www.eftel.net.au/~sup8pdct/indus1.gif

Page2 http://www.eftel.net.au/~sup8pdct/indus2.gif

Page3 http://www.eftel.net.au/~sup8pdct/indus3.gif

 

they were originally on paper size somewhere close to A3

 

James

Edited September 28, 2007 by sup8pdct