Jump to content
IGNORED

Indus doubler - zip of atr file


rcgldr

Recommended Posts

I changed the Indus doubler so that it is ATR "compatible". It is still double density 256 byte sectors, but sector 1 now loads the actual code from sectors 4 through 7, avoiding the 128 byte limit issue on sectors 1 to 3. I haven't changed the verify after write code yet (it checks CRC and only compares the first byte repeatedly, instead of comparing the entire sector). Note only sectors 1, 4, 5, 6, 7 are used. The rest of the sectors are all zeroes and not used. Link to zip of the atr file, or you can use the attachment.

 

http://rcgldr.net/atari/dblr1.zip

 

To use the doubler, insert the disk, then hold down "drive type" and then press "error". After it loads, I usually press "track" to switch to track display. This will put the Indus into a mode that emulates a 1050 doubler. You need to power cycle the Indus to get it out of emulation mode.

dblr1.zip

Edited by rcgldr
  • Like 5
Link to comment
Share on other sites

Works like a charm!!!!

 

No performance or operational difference with original floppy-based version, relying on 256-bytes sectors (1-3)...

 

Meets SDX performance, right on SDX environment (4.49c) with Ultra-speed format (which is now enabled on SDX's format utility). Effective throughput is close to 3,000 bytes/sec. (double-density and ultra-speed sector interleave).

 

Exceeding that number can only be achieved with SuperSynchro. or native SDX Indus.sys uploaded code into Indus, all combined with DOS-XL special sector interleave format... unless, of course, Indus-Doubler is tweaked to handle DOS-XL interleave, which in that case, it will very likely match the above, as well.

 

Also, transferred Goonies from Nuxx drive (@ $0A speed divisor) to Indus-GT (with Indus-Doubler) via MyCopyR 2.1, formatting with Ultra-interleave. It loads at more than double the original speed... SDX not needed in any form or shape.

 

The best part of all: it works on ANY Indus-GT with firmware 1.20 (!) If you have that version, then NO special HW, case-opening, soldering, piggy-backing or any of the crap needed on my 1050 to make it faster!

 

THANKS FOR SUCH GREAT WORK!!!!

  • Like 3
Link to comment
Share on other sites

Looking through the code, it would appear that special format command doesn't appear to handle 1050 format properly. Am i correct on this?

 

James

I'm not sure, the code should be similar to what is in the Indus ROM. Look for references to EMUMOD.

Link to comment
Share on other sites

I forgot to mention, dblr2.atr only added two lines of code to the entire program, used for the verify after write ("W") command, starting at line 299 in XDBL.MAC. Before this change, the compare loop just compared the first byte either 128 or 256 times. Note this is only done if the CRC is good. The odds of a good CRC with bad data are pretty low, about 1 in 65536. Floppy CRC is the product of two binary "prime" numbers: hex 0003 times hex F01F = hex 11021. The 3 will detect any odd parity error, and the 11021 will detect any single burst error less than 17 bits long.

FNW0:	LD	A,(DE)
	CP	(HL)
	JR	NZ,FNW2
	INC	DE      ;added this line
	INC	HL      ;added this line
	DJNZ	FNW0

Edited by rcgldr
  • Like 2
Link to comment
Share on other sites

I was finally able to test this tonight. Using my IndusGT (with RamCharger) and SDX, I ran the RWTEST utility. Read & Write times were nearly identical, 2973 bytes/sec.

 

I was also able to format a disk using the UltraSpeed skew, and read from all of my old USDoubler disks. Quite a cool thing!

  • Like 2
Link to comment
Share on other sites

Did you try enhanced density format with skewed sectors? I don't believe The code properly supports that. Should be an easy fix tho.

 

James

For "skewed" or "interleaved" sectors, assuming the Atari side uses the "f" format with interleave command, the interleave table is part of the command (along with number of sectors per track), which the Indus doubler passes along to the Indus firmware for a format.

Link to comment
Share on other sites

I ask this because the special format command doesn't check for 1050 emulation. It sees 128 bytes sectors and assumes single density but with 26 sectors. So my guess is it wont work.

 

James

There's a check here for double density from the parameter buffer + 7 in the format with interleave function on line 407. It's been so long that I don't recall if I verified this.

	LD	A,(BUFFER+7)	;BR IF SGL DENS
	SUB	80H
	JR	Z,FNI0
	LD	A,EM815		;SET 815 MODE
FNI0:	CALL	FMT

Edited by rcgldr
Link to comment
Share on other sites

lol, funny thing is I'm almost always in either single or double on all my drives, but yet back in the day I formatted a crap ton of enhanced disks....until I doubler'ed, happied, and xf'd....then it was back to single and double... skipped the in between.... I guess it was just easier that way, perhaps not wasting storage capacity of a disk?

Edited by _The Doctor__
Link to comment
Share on other sites

Not talking about double.

Remember enhanced is 26 128 byte sectors using MFM. I dont see where this is checked and 1050 mode set if required.

 

James

Tested this in SDX 4.49c. Indus gives me an F9 error when trying an enhanced density format with Ultraspeed skew. Tran counter went from 0-39 twice, then I got the error. Normal skew works. HSpeed fails before attempting the format.

Link to comment
Share on other sites

Not talking about double.

Remember enhanced is 26 128 byte sectors using MFM. I dont see where this is checked and 1050 mode set if required.

 

James

I knew about that. I only have Sparta Dos 2.3, since this was one of the formats back then, there should be someway I can force this? Currently I edit on PC, use SIO2PC software to go from mirrored single density to double density image using DOS, then boot into CP/M and use ICDS to transfer to CP/M, where I can build a test code. ICDS doesn't support single density dos transfer, and APE mirror doesn't support double density dos emulation, so there's an extra step. I'll check to see if there's enough space to put Wordstar on a "build" floppy for CP/M so I can do this from CP/M and then update the PC file later. I'm low on floppy disks, but I've ordered some and it's currently being shipped, which should help.

Edited by rcgldr
Link to comment
Share on other sites

Not talking about double.

Remember enhanced is 26 128 byte sectors using MFM. I dont see where this is checked and 1050 mode set if required.

 

James

Based on the timing, the Indus is either trying to format 26 128 byte sectors in single density or 26 256 byte sectors in double density, overwriting the tracks, causing this problem. I'll look into this.

Edited by rcgldr
Link to comment
Share on other sites

The 1050 enhanced mode should be fixed now. The fix was to assume that a format with interleave with 26 sectors is 1050 enhanced mode.

 

link to zip of dblr3.atr

 

http://rcgldr.net/atari/dblr3.zip

 

link to source code:

 

http://rcgldr.net/atari/YDBL.MAC

 

Side note - The interface to the Indus ROM uses 2 x track number. Was there a version of Indus GT that supported double sided floppies?

  • Like 6
Link to comment
Share on other sites

The 1050 enhanced mode should be fixed now. The fix was to assume that a format with interleave with 26 sectors is 1050 enhanced mode.

 

link to zip of dblr3.atr

 

http://rcgldr.net/atari/dblr3.zip

 

link to source code:

 

http://rcgldr.net/atari/YDBL.MAC

 

Side note - The interface to the Indus ROM uses 2 x track number. Was there a version of Indus GT that supported double sided floppies?

 

IT WORKS (!!!)

 

About 2060 Bytes/sec. (w) and 2192 Bytes/sec (read). It takes SDX "Ultra Skew" setting (as it was inoperant before)

 

And we are just getting started here! Have not even opened the drive, yet! :-)))

 

Just wait until we can format with DOS XL special Sector Interleave / Skew, or even your smoking-hot CP/M Interleave (I've never seen an Indus blaze a DD disk as fast as that!) ... ;-)))

 

Cheers!!!

  • Like 2
Link to comment
Share on other sites

Awesome job,

And fast work too!

 

You have taken my Indus back to it's proper place of prominence from the secondary alternate D1: and D4: slot and moved it back to the Primary Active D4: Primary alternate D1: slot! It is on the primary machine primary drive stack again!

 

If this had been offered with the Indus from day one... they would have tripled their sales!

 

-Just saying

_The Doctor__

Edited by _The Doctor__
  • Like 1
Link to comment
Share on other sites

Very very cool, just getting started indeed.... I'm thinking since the hardware is obviously capable of a higher divisor since indus Super Syncromesh is natively divisor 6 / 69kbps, it could negotiate (at least!) this speed using the Ultraspeed protocol instead to achieve the same speed, but with much more software compatibility.

 

Existing unmodified 'ultraspeed' formatters would still default to laying down the skew ideal for 54000bps operation, so they would need to be updated with an option for a faster skew (3:1? 4:1?) similar to SuperSyncroMesh format.

 

Then you have the best of both worlds. The speed of the fastest non track buffered indus native syncromesh, but using the well supported ultraspeed protocol.

 

The next phase would be for drives with RAMchargers, which could do full track, or dynamic buffering, which could be implemented / optimized in all sorts of ways.

Edited by Nezgar
  • Like 2
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...