For that matter...why would a PDD or pdd server even allow for 64k? How could a 100 make any use of a 64k file when a 100 only has less than 30k (in any given bank) available in total, ever, under any circumstance.
Database routines that do direct access entirely on-disk only? -- bkw On Feb 25, 2017 8:12 PM, "Brian White" <[email protected]> wrote: > 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 >>> >>
