rcgldr Posted June 25, 2018 Share Posted June 25, 2018 (edited) 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 June 25, 2018 by rcgldr 5 Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted June 25, 2018 Share Posted June 25, 2018 Very nice. I intend to put it through it's pace today and tomorrow. 1 Quote Link to comment Share on other sites More sharing options...
sup8pdct Posted June 25, 2018 Share Posted June 25, 2018 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 Quote Link to comment Share on other sites More sharing options...
Faicuai Posted June 25, 2018 Share Posted June 25, 2018 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!!!! 3 Quote Link to comment Share on other sites More sharing options...
rcgldr Posted June 25, 2018 Author Share Posted June 25, 2018 (edited) I think I fixed the verify (compares all bytes), the odds of CRC failure is rare, but this should fix the verify, and it doesn't seem to break anything. Link to zip of dblr2.atr http://rcgldr.net/atari/dblr2.zip Link to source code: http://rcgldr.net/atari/XDBL.MAC Edited June 25, 2018 by rcgldr 1 Quote Link to comment Share on other sites More sharing options...
rcgldr Posted June 25, 2018 Author Share Posted June 25, 2018 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. Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted June 26, 2018 Share Posted June 26, 2018 I renamez my copy inddblr2.zip to makes it more identified on my terribly not organized hard drive... nice work again!.... I guess I will have to play around the day after tomorrow as well. Quote Link to comment Share on other sites More sharing options...
rcgldr Posted June 26, 2018 Author Share Posted June 26, 2018 (edited) 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 June 26, 2018 by rcgldr 2 Quote Link to comment Share on other sites More sharing options...
+Stephen Posted June 27, 2018 Share Posted June 27, 2018 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! 2 Quote Link to comment Share on other sites More sharing options...
sup8pdct Posted June 27, 2018 Share Posted June 27, 2018 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 Quote Link to comment Share on other sites More sharing options...
+Stephen Posted June 27, 2018 Share Posted June 27, 2018 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 I did not try that. I'll give it a go shortly. Quote Link to comment Share on other sites More sharing options...
rcgldr Posted June 27, 2018 Author Share Posted June 27, 2018 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. Quote Link to comment Share on other sites More sharing options...
sup8pdct Posted June 28, 2018 Share Posted June 28, 2018 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 Quote Link to comment Share on other sites More sharing options...
rcgldr Posted June 28, 2018 Author Share Posted June 28, 2018 (edited) 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 June 28, 2018 by rcgldr Quote Link to comment Share on other sites More sharing options...
sup8pdct Posted June 28, 2018 Share Posted June 28, 2018 (edited) 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 Edited June 28, 2018 by sup8pdct Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted June 28, 2018 Share Posted June 28, 2018 (edited) 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 June 28, 2018 by _The Doctor__ Quote Link to comment Share on other sites More sharing options...
+Stephen Posted June 28, 2018 Share Posted June 28, 2018 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. Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted June 28, 2018 Share Posted June 28, 2018 (edited) for Sparta hspeed fail can be normal... try 4.47 and 4.49d they are different.... try classic I/O mode also .. Edited June 28, 2018 by _The Doctor__ Quote Link to comment Share on other sites More sharing options...
rcgldr Posted June 28, 2018 Author Share Posted June 28, 2018 (edited) 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 June 28, 2018 by rcgldr Quote Link to comment Share on other sites More sharing options...
rcgldr Posted June 29, 2018 Author Share Posted June 29, 2018 (edited) 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 June 29, 2018 by rcgldr Quote Link to comment Share on other sites More sharing options...
rcgldr Posted June 29, 2018 Author Share Posted June 29, 2018 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? 6 Quote Link to comment Share on other sites More sharing options...
Nezgar Posted June 29, 2018 Share Posted June 29, 2018 That's probably more to do with double stepping a mech/stepper designed for 80 tracks. 1050's double step for 40 tracks too I believe. Quote Link to comment Share on other sites More sharing options...
Faicuai Posted June 29, 2018 Share Posted June 29, 2018 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!!! 2 Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted June 29, 2018 Share Posted June 29, 2018 (edited) 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 June 29, 2018 by _The Doctor__ 1 Quote Link to comment Share on other sites More sharing options...
Nezgar Posted June 29, 2018 Share Posted June 29, 2018 (edited) 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 June 29, 2018 by Nezgar 2 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.