Indus GT rom disassembly Pt 2

[sup8pdct]

Have added more comments to what I have worked out.

There is a segment of code stating at $88B that loads and writes to the ROM.

Anyone work out what this is for??

Have looked at the built in high speed routines that don't work.

It used the clock out line on the sio buss to time getting data.

not sure speed it was supposed to be but is slower then 38,400.

Have included T states for the sio and total for sending/receiving 1 bit.

 

208 t states /19200 $28 pokey divisor 18866-pal

104 t states 1st version of syncromesh /38400 $10 pokey divisor 38553-pal 38847-ntsc

76 t states usd version of rom /52631 $A pokey divisor 52160-pal 52558-ntsc

58 t states 2nd version of syncromesh /68965 $6 pokey divisor 68209-pal 68730-ntsc

 

 

Also included comments where the Indus CP/M init command enters the rom to format a disk.

This occurs in 4 Places.

There is a web site describing how to set up an Indus CP/M disk from the ATR file and adding extra data

with a PC with a 360K floppy.

It is possible to get the indus to fix sectors 2 and 3. A small program will need to be written for the indus

for this to happen.

Have had a quick look at the LDW CA2001 indus clone rom.

Functionally, it is exactly the same except for version numbers and copyright notice,

BUT 3/4 of the routines have been shifted around a bit so many direct calls to rom won't work.

This breaks syncromesh and the CP/M INIT command but it would be possible to fix these.

 

The rom also includes commands for the use of a 1770 FDC but no indus has ever shipped with one of these.

INDUS12a.txt

[trub]

Good work!

 

Have had a quick look at the LDW CA2001 indus clone rom.

Functionally, it is exactly the same except for version numbers and copyright notice

AFAIK, LDW ROM is the same as the newer Indus GT ROM (ver. 1.2). CA-2001 returns version number of 2.01.

ROMs are available on Jerzy Sobola's site:

Indus 1.10 (the file name is misleading)

Indus 1.20 / LDW 2000

CA-2001

Take a look at the Synchromesh code (GTSYNC.COM from DOS XL or INDUS.SYS from SDX). It handles both 1.1 and 1.2 by loading different Z80 code chunks to the drive depending on the ROM version (which is determined first).

It is possible to get the indus to fix sectors 2 and 3. A small program will need to be written for the indus

for this to happen.

Such utility is under development

Edited September 12, 2008 by trub

[ataridano]

Also included comments where the Indus CP/M init command enters the rom to format a disk.

This occurs in 4 Places.

There is a web site describing how to set up an Indus CP/M disk from the ATR file and adding extra data

with a PC with a 360K floppy.

 

Would you be willing to point us to that site or explain a little more about how this works? I've had an Indus for years and thought that the ability to run CP/M was just one of those planned upgrades that never came to be!

[sup8pdct]

Good work!

 

Have had a quick look at the LDW CA2001 indus clone rom.

Functionally, it is exactly the same except for version numbers and copyright notice

AFAIK, LDW ROM is the same as the newer Indus GT ROM (ver. 1.2). CA-2001 returns version number of 2.01.

ROMs are available on Jerzy Sobola's site:

Indus 1.10 (the file name is misleading)

Indus 1.20 / LDW 2000

CA-2001

Take a look at the Synchromesh code (GTSYNC.COM from DOS XL or INDUS.SYS from SDX). It handles both 1.1 and 1.2 by loading different Z80 code chunks to the drive depending on the ROM version (which is determined first).

It is possible to get the indus to fix sectors 2 and 3. A small program will need to be written for the indus

for this to happen.

Such utility is under development

 

I do know all of that. A quick dissembly of the CA-2001 rom shows it is a copy of the indus 1.2 rom but the routines have been moved around a bit.

Eg: routine No 1,2,3,4,5,6 in the indus would be 1,3,4,5,6,2 in the CA. they also changed the version number returned and the copyright notice at the end of the rom.

I have only included the ver 1.2 syncro code as the rom was 1.2. sorting out the ver 1.1 from the 1.2 in the syncro code took a little bit of work.

The indus rom has an error when it comes to the write with read verify. the code checks the 1st byte of the sector by the number of times there are bytes in the sector.

 

James

[sup8pdct]

Also included comments where the Indus CP/M init command enters the rom to format a disk.

This occurs in 4 Places.

There is a web site describing how to set up an Indus CP/M disk from the ATR file and adding extra data

with a PC with a 360K floppy.

 

Would you be willing to point us to that site or explain a little more about how this works? I've had an Indus for years and thought that the ability to run CP/M was just one of those planned upgrades that never came to be!

 

Every thing you need to know is here http://trub.atari8.info/index.php?ref=indus_cpm_en.

including how to make a clone of the ramcharger. something i am yet to do but i will do it.

 

James

[ataridano]

Every thing you need to know is here http://trub.atari8.info/index.php?ref=indus_cpm_en.

including how to make a clone of the ramcharger. something i am yet to do but i will do it.

 

James

 

Thanks! I did some searching after my last post, and found the site, but didn't find much information after that point. I don't want to hijack the thread, but I wanted to ask a couple questions about CP/M for the Indus. From reading other sources, it looks like the A8 is booted with a normal boot disk, a terminal program is loaded, and then the Indus (through a button combination) boots a CP/M disk using the A8 for all I/O. The Atari's first drive has to be the Indus, the second can be used as a second CP/M drive. There were some issues getting CP/M images initally because A8 disks have sectors 1-3 as 128 byte, even on DD disks, CP/M does not. What I'm wondering is:

 

- Can the Atari format a disk with all 256 byte sectors or is there a hardware limitation forcing sectors 1-3 to be 128 byte? (I'm guessing this is something the drives do in their firmware)

 

-The Indus has density switches on the back, which seem useless, are these used for CP/M?

 

- Is the CP/M disk format used with the Indus similar to anybody else's, such as Kaypro or Osborne?

 

- Can that secord Atari drive accessable through the Indus running CP/M be larger than 180k, like 16M?

 

I've got a C128 that I've hung onto because I thought it was neet to have a CP/M machine, but it has it's quirks... and it sounds like the Atari + Indus may blow the doors off the Commodore

[ijor]

There were some issues getting CP/M images initally because A8 disks have sectors 1-3 as 128 byte, even on DD disks, CP/M does not. What I'm wondering is:

 

- Can the Atari format a disk with all 256 byte sectors or is there a hardware limitation forcing sectors 1-3 to be 128 byte? (I'm guessing this is something the drives do in their firmware)

 

A8 double density disks have all sectors as 256 bytes, including the first 3 sectors. The drive just ignores the second half of the sector.

 

The problem you have is how to "transmit" and "copy" these disks. If you try to copy or image them (by normal means), then the content of the second half of those sectors would be lost.

 

P.S.: The only exception is the Duplicator that does format those sectors as 128 bytes. This makes Double Density disks formatted in the Duplicator to be incompatible with some of the other DD drives (such as Happy).

[trub]

- Can the Atari format a disk with all 256 byte sectors or is there a hardware limitation forcing sectors 1-3 to be 128 byte? (I'm guessing this is something the drives do in their firmware)

Yes, it can, the DD disk has physically all sectors equal in size, AFAIK there is only a software limitation.

- Is the CP/M disk format used with the Indus similar to anybody else's, such as Kaypro or Osborne?

The CP/M disk format is somehow standarized but it doesn't mean that actual diskettes can always be used with different systems.

- Can that secord Atari drive accessable through the Indus running CP/M be larger than 180k, like 16M?

No, current implementation allows only DD (via A: and B:) and SD (C:) disks (however I run into certain problems with the latter).

 

I am currently working on Indus CP/M BIOS module disassembly, so that it can be modified/extended for particular needs.

[ijor]

- Can the Atari format a disk with all 256 byte sectors or is there a hardware limitation forcing sectors 1-3 to be 128 byte? (I'm guessing this is something the drives do in their firmware)

Yes, it can, the DD disk has physically all sectors equal in size, AFAIK there is only a software limitation.

 

For a "normal" DD drive (like USD, or XF-551), it is a firmware limitation. The firmware will not let you read or write the second half of those sectors.

 

With programmable drives, like Happy, software can always override the firmware, and then it becomes a software limitation "only".

[sup8pdct]

For those with LDW CA-2001 and ram charger, the CP/M init command won't work.

The following should fix this little problem.

 

Disk edit program on PC or directly editing the file:

 

Find bytes: change from: change to:

78,CD,F4,07 F4,07 41,08

80,CD,44,0B 44 05

 

If you are using a disk edit program on the atari, those bytes will be inverted.

I cannot test the changes as I don't have a ramcharger (yet) and the LDW drive/rom for my indus.

 

The indus init command for cpm makes direct calls to the indus rom in 4 places.

The LDW rom has 2 of the requires routines shifted around. the above changes should correct things.

 

James

[ataridano]

If you are using a disk edit program on the atari, those bytes will be inverted.

I cannot test the changes as I don't have a ramcharger (yet) and the LDW drive/rom for my indus.

 

Speaking of the Ramcharger, I realize the board is probably pretty simple to hand build, but do you think there would be enough interest to make a PCB? I don't mind building something on proto-board but the Indus is kinda rare and I'd have to damage it by connecting a wire to the wrong place or something...

[Freshy]

I would be interested in a PCB. I have four or five GTs, and little skill to make my own ramcharger. I am a bit of a programmer and have been reading up on Z80 assembly. I think there are a lot of software mods that could be done with these drives. Especially if they have the 64K available to work with.

 

I downloaded TinyCAD and tried to get the schematic drawn so I could export it into another program to make the layout. But, I was never very confident that I was getting the pinouts oriented right......

[Mathy]

Hello guys

 

Since Guus Assmann now also visits AtariAge, why not ask him. He can do a layout faster then anyone else.

 

Greetings

 

Mathy (who doesn't have an Indus GT, but who would consider buying one, if it could be upgraded to Double Sidedness.)

[ataridano]

Hello guys

 

Since Guus Assmann now also visits AtariAge, why not ask him. He can do a layout faster then anyone else.

 

Greetings

 

Mathy (who doesn't have an Indus GT, but who would consider buying one, if it could be upgraded to Double Sidedness.)

 

I would be willing to do the layout too.. but I don't know the much about the inner workings of the Indus and could easily screw things up. It is too bad that the Indus doesn't use a standard mech. so we could easily make it double sided. I think it would be very neet to get some Z80 code running on the Atari (so to speak), and even cooler if the "terminal" program was more of a co-processor (maybe it is) so that the Indus could tell the Atari to access any devices connected an tell it to display graphics. Well, first things first, gotta get a ramcharger

[Mathy]

Hello Ataridano

 

I think it would be very neet to get some Z80 code running on the Atari (so to speak), and even cooler if the "terminal" program was more of a co-processor ...

With the right software, the Indus could be used as a co-processor. But maybe an upgraded 1050 with a 650x processor could be too.

 

Greetings

 

Mathy

[trub]

Speaking of the Ramcharger, I realize the board is probably pretty simple to hand build

In fact, the SRAMCharger schematics/board can be even simpler. One larger SRAM memory can be used (instead of two 32kB) with appropriate TTL chip. I'm going to put this alternative design on the SRAMCharger page soon. Till then I can give details via PM if someone is interested.