Filesize limit is a bit of a suprize, because this is a 600, not 100/102/200. It doesn't use the same cpu, or the same kind of rom (except vaguely, from 10,000 feet) It has just over 220k free when all possible ram is installed, and that's all in one space, not in banks. It doesn't use PDD at all but has a built in floppy. It's an entirely different OS.
But I just tried to edit a file in WORD by just typing some junk and then copy/paste until it wouldn't go any further. Cleared the copy buffer and manually typed a little more until it wouldn't go any more. Copied the file to disk. Deleted the file from ram. Noted the free space (220512), copied the file back from disk. Noted the new free space (156912). So you can't create a WORD doc larger than 63,600 bytes. So maybe there is a generic universal file size limit of 64k on this machine, not just an xmodem or telcom limit. After the word doc experiment, the xmodem limit is no longer a suprize now of course. The 64k-1byte might not be unusual as a limit, but it's definitely a bug to say you handled 65536 bytes without error while you actually only handled 65535 bytes. Serial port speed is set at 9600, but apparently the bottleneck is bios routines. It's been discussed before inarchived posts. It effectively runs about the same as 600bps regardless of serial port settings. Also, telcom will let you set the rate as high as 19200 but xmodem transfers fail after just a few k at that speed. I tried 1200 and it was no slower or faster. -- bkw On Feb 25, 2017 5:33 PM, "John R. Hogerhuis" <[email protected]> wrote: > Serial sniffer would tell you. > > Xmodem probably limited to 64k by protocol without extensions. > > Taking 10 minutes seems slow. What speed? > > -- John. > > > On Sat, Feb 25, 2017 at 1:55 PM Brian White <[email protected]> wrote: > >> Random model 600 discoveries while trying to test the new ram boards more >> rigorously. >> >> Idea was to: >> >> Populate both slots, which makes a little over 220k available. >> >> Generate about 256k of random binary data on a modern machine. I just >> copied 256k of random stuff and used gpg on it a few times randomize it >> thoroughly. >> >> Xmodem the blob to the 600 until it aborts. >> >> Xmodem the blob back to the pc. >> >> Use dd to copy out a truncated excerpt from the original blob of exactly >> the same size as the blob that came back from the 600. >> >> Binary compare the two truncated blobs. >> >> >> I encountered 2 things: >> >> You can't xmodem more than 64k in one file. >> >> So I split the 256k blob into 4 64k blobs and discovered the next thing. >> >> You can't *actually* xmodem more than 64k *minus one byte*, in a single >> file. >> >> If you try to send a file over 64k and allow telcom to truncate it at >> 64k, or if you try to send a file that is exactly 65536 bytes, you will >> transfer 65536 bytes both ways, and neither side of the connection will >> issue any warnings or errors. Both TELCOM and the xmodem util on the modern >> machine will say everything went fine. But if you transfer a 65536 byte >> file from a pc, to the 600, and back, the final byte will be changed from >> whatever it was to a 0x20 space. All other bytes are preserved. >> >> If you transfer a file 65535 bytes or less, the file makes it both ways >> 100% accurate. >> >> I don't yet know when the change takes place. Is it when telcom receives >> the file from the pc, or when telcom sends the file to the pc? Both? There >> are a few ways to test the individual parts, just it's soooo sloooow. It >> takes about 10 minutes to transfer 64k. >> >> I think this mostly proves out the ram boards, as well as can be without >> an actual ram test program. To really be sure, I should swap the 2 boards >> between slots 1 & 2, and repeat the whole process. Ugh. >> >> -- >> bkw >> >
