5 Feb
2019
5 Feb
'19
2:22 p.m.
On 2/5/2019 12:03 PM, Fritz Mueller via cctalk wrote:
At 9600 bps, and allowing for 10 bit characters (8 data bits, 1 start, 1
stop), that is 960 cps, and 2.5MB RK05 should take under an hour (2400
s). Round that up to an hour, say, for handshaking overhead, etc. That
is consistent with your read time.
To get to three hours we would need a pause for each write of:
7200 = 200 (tracks) x 12 (sectors/trk) x 2 (sides) x n seconds/block
And n would be 1.5 seconds / sector for the write time. That seems
excessive.
Perhaps it is doing read after write verify for each block written? If
so, can you turn that verify off? (When I do my transfers over a DR11,
I run a separate checksum step afterwards, and the transfer programs
also report their checksums).
Perhaps
compile [test programs] under SimH and do a block-level diff of the image with what is
currently in use, and transfer just those blocks?
I did experiment with this a little way back. I wrote a small standalone code that dumps
a CRC of every sector over the console; I can run this both under SIMH and on the real
machine, then diff to find the changed sectors.
Unfortunately, when I tried to apply this, it seemed that SIMH's write single sector
wasn't working correctly for me (though "write all sectors to end" seemed to
work okay). It ended up being much more tedious than I had thought to do it this way; in
the end I concluded I'd be better off writing some different software specifically for
this purpose, but I haven't gotten back to it yet.
FWIW, I maintain a Windows VM (on a MacOS X host) for the sole purpose of running
PDP11GUI, and I use an USA19H USB serial dongle connected through to the VM as a serial
interface. I don't know if something about this setup is particularly detrimental to
PDP11GUI transfer performance? It takes me >3hrs to write a 2.5mb pack this way (at
9600 baud), or a little over 1hr to read one back. Do others see similar throughput with
these tools?
--FritzM.