Indus "doubler"

[+Nezgar]

Well bummer that. I always assumed (since I got it back in 89) that my US Doubler was exactly 3X faster. I've been lied to for the past 3 decades.

It may still be. This is purely the rate of the serial transfer though. Aside from that, the US Doubler's optimized sector skew about was about 13% faster even for standard skew disks when used at 1x SIO, reducing the inter-sector wait time even for those then using the disks in a stock 1050. (This same skew was seen earlier in the 810 archiver, also created by Mike Gustafson - the precurser to the US Doubler ) There may also be optimizations with inter-track first sector start/skew as well, so that it can read the first sector of the next track with minimal rotational delay. With that in mind, the real-world throughput of a US Doubler with an UltraSpeed skew disk may indeed be 3x faster in practice.

 

Time for me to break out RWTEST tonight to see

 

I did confirm in the past that for pure sequential reads/writes, the USDoubler with ultraspeed skew beats the happy marginally because the happy takes extra time to buffer whole tracks, and buffered track writes also incur an additional rotation to verify.

Edited June 11, 2018 by Nezgar

[rcgldr]

It may still be. This is purely the rate of the serial transfer though

 

If the drives used a UART instead of bit banging, then host communication could occur in parallel with disk I/O operations, doubling the speed, but then there may be a limit on the baud rate versus the specified length of the SIO cables.

 

On a side note, I thought a had a formula that worked for most of the speeds, but not for a divisor value of 8. What I suspect is the count down timer cycles during a transition from 0 to -1 as opposed to from 1 to 0, using the "borrow" bit as the cycle trigger. Then the 6 cycle delay noted in the spec should mean that the bit rate = (1790000 / (divisor+7))/2 or 895000 / (divisor+7). Using some examples, hex 5cc = 1484: 895000/(1484+7) = 600.3 bps. 895000/(40+7) = 19042.55 bps, close to the spec rate of 19040 bps. 895000/(10+7) = 52647 bps, close to the drives doubler speed of 52631 bps (19 us per bit). However, 895000/(8+7) = 59667 bps, not 57600 bps. While 89500(6+7) = 68846 bps, close to the 68695.5 bps stated for super syncromesh rate (58 cycles = 14.5 us per bit, with 4mhz Z80, this is not possible with 1mhz 6502).

[sup8pdct]

Can you please tell me how the write with read verify works where it compairs what was read with what was originally written?

Code is:

LD HL,(CURBUF)
LD DE,VERBUF
FNW0: LD A,(DE)
CP (HL)
JR NZ,FNW2
DJNZ FNW0

 

I think it checks the 1st byte of the sector 128/256 times, not the whole sector.

 

James

[rcgldr]

Can you please tell me how the write with read verify works where it compairs what was read with what was originally written?

Code is:

LD HL,(CURBUF)

LD DE,VERBUF

FNW0: LD A,(DE)

CP (HL)

JR NZ,FNW2

DJNZ FNW0

 

I think it checks the 1st byte of the sector 128/256 times, not the whole sector.

 

James

I recall fixing that (there should be INC DE and INC HL before the DJNZ instruction). I still can't find the 5.25 inch floppy drives I used for the ATR8000, or the set of "master" 5.25 inch floppy disks I had at the time. What I did find were older copies of this stuff scattered about in storage bins (totes). I'm missing a tote. I'm pretty sure that the retailer that included a free copy of the Indus doubler to customers that bought the Indus GT had the fixed version. I'm wondering if Indus ever released their version of the doubler, since I haven't found anyone else that reported getting a copy of it from Indus.

 

I can easily fix the source again, but I need to wait for an SIO2PC that I ordered to arrive, so that I can get the source code and Z80 assembler onto an Indus CP/M disk (or virtual disk) in order to get a fixed copy of the bootable doubler. The ATR8000 is no longer an option since I'm missing a storage bin.

Edited June 12, 2018 by rcgldr

[Faicuai]

While 89500(6+7) = 68846 bps, close to the 68695.5 bps stated for super syncromesh rate (58 cycles = 14.5 us per bit, with 4mhz Z80, this is not possible with 1mhz 6502).

This is VERY interesting because... the very best I've managed to extract from Super Synchro is close to 45 Kbps (effective) direct from RamCharger (and no rotational activity). That is. full 23 kbps short of the theoretical 68.8.kbps.... I am having a hard time believing DOS XL alone is responsible for chewing 23 kbps of throughput.

 

Something does not add up...

[rcgldr]

This is VERY interesting because... the very best I've managed to extract from Super Synchro is close to 45 Kbps (effective) direct from RamCharger (and no rotational activity). That is. full 23 kbps short of the theoretical 68.8.kbps.... I am having a hard time believing DOS XL alone is responsible for chewing 23 kbps of throughput.

 

Something does not add up...

I'm not sure what the issue is. Those are the calculated bit rates assuming Pokey divisor of 6 on the Atari side, and 58 cycles or 14.5 us per bit on the Indus side. What I'm wondering about is if the sector image is being moved in memory on the Atari and/or Z80 side. The Z80 side internal memory transfer would take about 1.3 ms, the Atari side about 1.7 ms, which wouldn't add much to the transfer time of 37.12 ms per sector at 68.8 kbps. So even if both sides move memory, that's 40 ms per sector, or about 64 kbps.

[sup8pdct]

The sdx version of super syncro has slightly altered timing when compared to original.

No idea if it affects things.

;
;--------------------------------------------------------------------------
;following 5 instructions have been swapped around by ICD for timing issues with SDX.
;orignal code follows
;-------------------------------------------------------------------------
;
SIOHIGHSPEED:
CALL SENDBYTEHS ; 7E9A CDCC7E patched
LD C,B ; 7E9D 48 save B
LD B,$5A ; 7E9E 065A count 5A
CALL CDOWNDELAY ; 7EA0 CD9E0C Count DOWN DELAY
LD B,C ; 7EA3 41 end patched

;SIOHIGHSPEED
; LD C,B ; 7E9A 48 orignal version
; LD B,$5A ; 7E9B 065A .Z
; CALL CDOWNDELAY ; 7E9D CD9E0C ...
; LD B,C ; 7EA0 41 A
; CALL SENDBYTEHS ; 7EA1 CDCC7E end orignal version

Re write with read verify check. it is the same in the drive firmware and in the syncro code. bit of an oops there

 

James

[Faicuai]

I'm not sure what the issue is. Those are the calculated bit rates assuming Pokey divisor of 6 on the Atari side, and 58 cycles or 14.5 us per bit on the Indus side. What I'm wondering about is if the sector image is being moved in memory on the Atari and/or Z80 side. The Z80 side internal memory transfer would take about 1.3 ms, the Atari side about 1.7 ms, which wouldn't add much to the transfer time of 37.12 ms per sector at 68.8 kbps. So even if both sides move memory, that's 40 ms per sector, or about 64 kbps.

 

I am not sure either (as your computations seem dead-on, to me).

 

But the reality seems a bit distant from these nominal bit-rates. For the sake of clarity:

 

1. Load DOX XL 2.35 + Super Synchromesh (make sure it is active).
2. Load ProCopy 2.0 or any other fast & efficient RAM-disk based copy utility (DO NOT use DOS).
3. Read or copy (a 48 Kbyte-long file) fully, and in ONE pass. It will fit entirely on IndusGT RamCharger's working memory.
4. Read or copy (immediately) SAME file, on ONE pass.... and make sure you HAND-time this operation.
5. Divide file-length by observed hand-times.

 

Here are some specific results:

 

1. 49,082 bytes read in 10.95s, entirely from RamCharger ram (no disk activity), and under DOS XL + Super Synchro. (~4,494 Bytes/sec, or 44,900 bps)
2. 49,082 bytes read in 9.10s, from NUXX SDrive + .ATR image, and under DOS XL (Super Synchro N/A). (~5,393 Bytes/sec, or 53,830 bpbs)

 

This is, in fact, a fundamentally simple question:

1. How much can [ Super Synchro + Z80 + RamCharger ] really handle, taking out of the equation the physical media (+ WD controller)?

 

In summary:

 

• It seems that in such scenario, we are a bit far from 68.8kbps, and I can't come up with a plausible explanation for this....
• I actually have many more tests, and (in read-operations) SDX kind of sucks relative to the above results, but actually trounces DOS XL in the write-speed department.

 

...

[rcgldr]

Read or copy (a 48 Kbyte-long file) fully, and in ONE pass. It will fit entirely on IndusGT RamCharger's working memory.

 

What is the directory structure for a DOS 2.0 file? Will the Atari side have to read sectors other than just the file data?

 

What if you found the starting sector of the file, and wrote a program that just read sectors sequentially from the RamCharger's memory, or perhaps just read the same sector repeatedly?

[Faicuai]

What is the directory structure for a DOS 2.0 file? Will the Atari side have to read sectors other than just the file data?

 

What if you found the starting sector of the file, and wrote a program that just read sectors sequentially from the RamCharger's memory, or perhaps just read the same sector repeatedly?

Thought exactly about this... although the Track counter jumps very briefly to 20, than back down to initial location of file, and from there on, it climbs non-stop, until the very last track of file, without ever looking back (again, this is under DOS XL 2.35 + Super Synchro.)

 

The above behavior leads me to believe that there is little overhead or, at least, not enough to swallow 23 Kbps from nominal 68.8kbps...

 

I am working on locating a sector reader that will work with Super Synchro... if I find it (I have a couple of candidates already), I will try a direct sector read... but something tells me this will not make that much of a difference, though...

 

UPDATE:

 

By using DOS XL-provided DUPDBL utility, performed a clean, direct read of first 7.25 tracks of a DD disk formatted under Super Synchro, which rounded-down equates to 32256 bytes, and all read in 7.28secs. All of this straight from RamCharger, no disk-soin whatsoever.

 

The above translates into 4,430 bytes /sec. which is pretty much consistent with prior track-buffered tests. In short, we are still quite a way from the mythical 68.8 kbps... Where the HELL did those 24 kbps go? Or are they simply ABSENT from Super Synchro? I guess a more thorough review of its code may be in order...

[+Nezgar]

Does DOS XL use the last 3 bytes on each sector for a sector link like DOS 2.0? Though I guess that would only account for 1.17% loss of real data throughput if so.

Edited June 12, 2018 by Nezgar

[rcgldr]

Re write with read verify check. it is the same in the drive firmware and in the syncro code. bit of an oops there

The odds of getting a good CRC, but a data mis-compare are 1 in 65536, and zero if there is only a single error burst less than 17 bits long, assuming a 16 bit CRC. Combine this error-misdetect with the actual error rate, and it's fairly unlikely to occur. Still, unless there's some magical hardware in the Indus, it's a bug in the code. I need to check if my Indus has the same bug in it's drive firmware.

[rcgldr]

A standard Indus GT ROM has it's own version of a DOS for programs loaded into RAM, it has 2048 bytes of ram, using 256 bytes for sector I/O, a few bytes for the interrupt vectors, leaving about 1700 bytes of space for an emulator program.

 

All of the interrupt vectors go through RAM, so that a booted program can easily replace the vector addresses to do things like intercept host commands for emulation mode.

 

Similar to a PC boot, the Indus only reads one sector, and runs it. The code in from that first sector then reads in the rest of the code.

 

The Indus GT can be used with a Commodore 8 bit computer, which I assume is a different protocol, and I don't know if this is done using a emulator boot floppy, or if they use a different ROM.

 

Update, there's only 1024 bytes available for a emulator, from 7C00H to 7FFFH (inclusive). There is a main sector buffer, a command / verify buffer, some variables used by the firmware, and stack space, which uses the ram from 7800H to 7BFFH (inclusive).

To reduce overhead, I use 5 sectors. Sector 1 gets loaded at 7F00H by the Indus firmware. It in turn reads sector 2 to 7C00H, 3 to 7D00H, 4 to 7E00H, and reads in sector 5 but leaves it in the default buffer. It then jumps to the code from sector 2 at 7C00H to do the final memory copy of sector 5 from the default buffer to 7F00H (otherwise it would be overwriting itself). This is a fairly generic boot sequence.

Edited June 13, 2018 by rcgldr

[JR>]

 

3. Read or copy (a 48 Kbyte-long file) fully, and in ONE pass. It will fit entirely on IndusGT RamCharger's working memory.

 

...

 

How do you activate the RamCharger as a buffer? I have an original RamCharger. It boots CP/M fine. When I boot with Super Synchromesh, the drive runs faster, but I've never been able to get it to re-read any amount of data without the disk spinning up. Is there something else that needs to be loaded in addition to GTSYNC to enable this?

 

Edited June 13, 2018 by JR>

[Faicuai]

How do you activate the RamCharger as a buffer? I have an original RamCharger. It boots CP/M fine. When I boot with Super Synchromesh, the drive runs faster, but I've never been able to get it to re-read any amount of data without the disk spinning up. Is there something else that needs to be loaded in addition to GTSYNC to enable this?

 

I boot DOS XL 2.35 with Super Synchro. After everything is said and done, a nice "bF" permanently appears on the track display. Whenever reading same tracks repeatedly. the actual track numbers / progression shows instead... and NO disk spinning takes place, at all (none, zero). And data buffered is REAL, because I have tested it on executables. Upon read-completion, track display remains on last read track and never returns to 39, as usual.

 

If you are not getting this, it is either a deffective RamCharger. or older ROM version (must be v1.2 per GT Diags utility) or wrong Super Synchro version, or a combination of any of these.

[JR>]

Thanks, I guess it actually is working. It acts exactly as you describe. The drive is so quiet, it's hard to tell if it's spinning or not in my noisy environment. I just expected the difference between buffered and non-buffered to be more significant and obvious I guess.

Edited June 13, 2018 by JR>

[ijor]

Btw, do we know the names of the main developers of the Indus? They deserve to be known