Indus GT rom disassembly

[sup8pdct]

I have disassembled the IndusGT V1.2 rom , the Syncromesh code, the ramCharger code and the loader for both.

I have put some comments to things I have worked out but it still needs work. (very big HINT)

The version Number of the rom is also stored at $CF5 for V1.2.

The SDX version of syncromesh excludes the ramcharger code and some changes are made to the loader as noted

Any comments, please let me know.

Have not checked if it will assemble yet.

 

James

INDUS12.txt

[drac030]

I think it would be useful to prepare an Indus GT ROM fixed so that:

 

1) we can finally get rid of Synchromesh (which is said only to fix bugs in the highspeed code, that is already there, but does not work)

 

2) nothing, and especially Indus CP/M, gets broken

 

Such a cleaned ROM could be also put into LDW Super 2000 and CA-2001 drives, which are basically Indus clones.

[sup8pdct]

I think it would be useful to prepare an Indus GT ROM fixed so that:

 

1) we can finally get rid of Synchromesh (which is said only to fix bugs in the highspeed code, that is already there, but does not work)

 

2) nothing, and especially Indus CP/M, gets broken

 

Hmmm Let me think about it. Could take 7 1/2 million.....................

The Indus CP/M part will need to be looked at to see what entry points are used, if any.

Have read that there are 2 parts to CP/M. CP/M it self and Hardware extentions.

No idea which is what and quite possibly a loooot of work.

The syncromesh part is self contained with jumps to the firmware where needed.

The Highspeed bitbang SIO is in the addon code. also included is sector maps for the Syncro format which looks exactly like USD format.

Also 1 extra command is added.

 

Any volunteers to dissemble the indus CP/M?????

 

James

[drac030]

Any volunteers to dissemble the indus CP/M?????

 

What for? It works with different Indus ROM versions (even with CA's v.2.1), so I guess it doesn't use any direct jumps to ROM routines, only legal entries or nothing at all. So it is just a matter of retaining the compatibility of the function table, retaining the function of the DRIVE/ERROR button, and not breaking the CP/M bootloader invoked with that key combo

 

As for CP/M, only BIOS would matter. Certainly trub can say more about it.

 

1 extra command is added by Synchromesh? This is interesting. What one?

Edited August 9, 2008 by drac030

[carmel_andrews]

Any chance of getting shot of the syncromesh mode and sticking in the betterknown USD mode (since it's more widely available...and more dos's support it)

[trub]

Indus CP/M BIOS invokes all drive functions through the legal vector at $0004.

There is one "illegal" jump in the INIT.COM program for initializing new CP/M diskettes. This makes it not quite compatible with the CA-2001 drive. However it can be fixed easily in the future, till then one should use an external format program in this case.

The drive ROM also handles DRIVE+ERROR key combination, which runs CP/M boot program from the first sector of a disk.

[sup8pdct]

already been done. check out older topics

 

james

[sup8pdct]

Any volunteers to dissemble the indus CP/M?????

 

What for? It works with different Indus ROM versions (even with CA's v.2.1), so I guess it doesn't use any direct jumps to ROM routines, only legal entries or nothing at all. So it is just a matter of retaining the compatibility of the function table, retaining the function of the DRIVE/ERROR button, and not breaking the CP/M bootloader invoked with that key combo

 

As for CP/M, only BIOS would matter. Certainly trub can say more about it.

 

1 extra command is added by Synchromesh? This is interesting. What one?

 

Must look for that key combo tho i would have thought that would have been a bit of extra code loaded to the indus when one loaded the terminal program for indus cpm.

 

Good to know that legal entry is used.

 

The extra command is $23 '#' for format with hs sector layout just like USD sector layout. Enhanced density hs sector layout isn't supported.

 

You can see it in the indus code @ 7BCD which jumps to 7BD8 with the sector tables @7D90

 

james

[sup8pdct]

I have disassembled the IndusGT V1.2 rom , the Syncromesh code, the ramCharger code and the loader for both.

I have put some comments to things I have worked out but it still needs work. (very big HINT)

The version Number of the rom is also stored at $CF5 for V1.2.

The SDX version of syncromesh excludes the ramcharger code and some changes are made to the loader as noted

Any comments, please let me know.

Have not checked if it will assemble yet.

 

James

Something I forgot to Add.

The write with read verify doesn't actually verify properly.

It checks the first byte only by the number of bytes in the sector.

You can see it starting at 2BB and 7C5A in the syncro code.

 

James

[Bryan]

I've actually seen a copy of the Indus source code when I briefly worked for Tom Harker at ICD. Did you know that the development name for the drive was the WART (Wonderful Atari Rotating Thing). Kinda weak, if you ask me. Anyway, I know the original source is out there somewhere.

[ijor]

I've actually seen a copy of the Indus source code when I briefly worked for Tom Harker at ICD.

 

Interesting.

 

How the source reached ICD? ICD purchased Indus at some point? Or was because some kind of cooperation between them?

[sup8pdct]

In the Indus field service manual, the main circuit board is referred to as the WART board.

Guess nothing much has changed...

 

James

[drac030]

Must look for that key combo tho i would have thought that would have been a bit of extra code loaded to the indus when one loaded the terminal program for indus cpm.

 

No, this key combo works even when nothing was loaded before. It loads the sector 1 to the drive's RAM (at $7F00) and jumps there to execute the code. Obviously it can be used to boot anything, not just CP/M.

 

As about the verify error, yes, I noticed the comment in your listing. So there'a at least one thing to fix already

 

The bad thing about the $23 Synchromesh command is, that the opcode is the same as DSDD formatting in the XF551.

Edited August 10, 2008 by drac030

[sup8pdct]

Must look for that key combo tho i would have thought that would have been a bit of extra code loaded to the indus when one loaded the terminal program for indus cpm.

 

No, this key combo works even when nothing was loaded before. It loads the sector 1 to the drive's RAM (at $7F00) and jumps there to execute the code. Obviously it can be used to boot anything, not just CP/M.

 

As about the verify error, yes, I noticed the comment in your listing. So there'a at least one thing to fix already

 

The bad thing about the $23 Synchromesh command is, that the opcode is the same as DSDD formatting in the XF551.

 

The things one learns. I must look for that code that does the loading.

 

Is good to see someone actually reading my sometimes correct comments in the listing

As for the Command, At least SDX is smart enough to know the difference.

The High bit is set anyway, so it may not interfere with the XF.

Don't know of any other dos that can talk to the indus and XF at highspeed, so that problem may never arise anyway

 

James

[drac030]

Is good to see someone actually reading my sometimes correct comments in the listing

 

Well, I hope for updates from you.

 

The SDX doesn't use the command, as far as I know.

[sup8pdct]

Is good to see someone actually reading my sometimes correct comments in the listing

 

Well, I hope for updates from you.

 

The SDX doesn't use the command, as far as I know.

 

Will try to make sure they are correct then..

 

I remember trying SDX formating the indus after the syncro load, and from memory it did work.

That was a long time ago so memory my be a little lacking...........

 

James

[drac030]

I remember trying SDX formating the indus after the syncro load, and from memory it did work.

 

I am sure it did - when you select "HighSpeed" in SDX formatter menu, the formatter will use $A1 ($21+$80) to format. It must be so that this command, too, selects the highspeed skew in Indus.

Edited August 10, 2008 by drac030

[Bryan]

I've actually seen a copy of the Indus source code when I briefly worked for Tom Harker at ICD.

 

Interesting.

 

How the source reached ICD? ICD purchased Indus at some point? Or was because some kind of cooperation between them?

No, Tom just got a copy of the tech docs from Indus. Probably because of work they were doing on SpartaDOS. Tom had all kinds of cool stuff. I remember he also had the source to the XF551 and other rare Atari docs. It all went away when he abandoned the ICD offices, though.

[+bf2k+]

...

 

It all went away when he abandoned the ICD offices, though.

 

Is ICD still in business? They still have a website -> www.icd.com

[Bryan]

...

 

It all went away when he abandoned the ICD offices, though.

 

Is ICD still in business? They still have a website -> www.icd.com

Not really. Tom keeps the website up for nostalgia reasons, but his full-time job is running rockriver.net.

[ijor]

No, Tom just got a copy of the tech docs from Indus. Probably because of work they were doing on SpartaDOS. Tom had all kinds of cool stuff. I remember he also had the source to the XF551 and other rare Atari docs. It all went away when he abandoned the ICD offices, though.

 

I guess that tons of invaluable stuff was lost on the ICD collapse

 

There is still a chance that Mike Gustafson kept something. Are you still in contact with Tom? Do you (or Tom) have any idea what happened to Mike? Mike Gustafson must be one of the third party Atari developers I admire the most.

[drac030]

Certainly, there are questions to him...

[Bryan]

No, Tom just got a copy of the tech docs from Indus. Probably because of work they were doing on SpartaDOS. Tom had all kinds of cool stuff. I remember he also had the source to the XF551 and other rare Atari docs. It all went away when he abandoned the ICD offices, though.

 

I guess that tons of invaluable stuff was lost on the ICD collapse

 

There is still a chance that Mike Gustafson kept something. Are you still in contact with Tom? Do you (or Tom) have any idea what happened to Mike? Mike Gustafson must be one of the third party Atari developers I admire the most.

Last time I talked to Tom, he hadn't heard from Mike in a long while.

 

ICD operated out of an old factory building in Rockford. It was cool because the place was huge and mostly empty. At different times they had occupied different parts of the building, but when I got there ICD was mostly confined to offices on the 6th (top) floor. The building was eventually sold to the city and Tom moved out with only what he needed to run the ISP. When he went back months later, the place had been looted.

 

From what I understand, Mike Hohman (FTe) lost most of the ICD stuff when he couldn't pay his storage bill and now the rest is gone.

 

-Bry

[carmel_andrews]

Bryan...wouldn't it have been an idea (at the time) to have asked tom if you could copy (for archival purposes only) all the original documentation (incl. doc's collated by icd from 3rd parties, like Atari and Indus etc), that way, this situation that you've just informed us of, would have been avoided....just a thought that is all

[Bryan]

Bryan...wouldn't it have been an idea (at the time) to have asked tom if you could copy (for archival purposes only) all the original documentation (incl. doc's collated by icd from 3rd parties, like Atari and Indus etc), that way, this situation that you've just informed us of, would have been avoided....just a thought that is all

 

I wasn't there when it happened. I left while Tom was operating out of the old building and I live 1400 miles (2250km) away.

 

Links:

 

The old factory at 1220 Rock St.

http://maps.google.com/maps?f=q&hl=en&...951047421214884

 

The old offices were on the top floor, to the left of the elevator tower in the middle:

http://maps.google.com/maps?f=q&hl=en&...640234470651479

 

-Bry