Hi all, > On Oct 10, 2020, at 4:26 PM, vtgearhead <snhirsch_at_gmail.com> wrote: > > Is anyone using CBM Commander 2.3 to copy REL files? I'm seeing very odd > behavior where the copy logic fails with error #70 (no channel or too many > channels open). I haven't, but your description of the symptoms intrigues me. > After setting up to build cbmcmd from source code and > sprinkling in some print statements, it looks like this sequence fails: > > file # 15 is opened on error channel of source drive > file # 2 is opened on source file itself, with secondary of 2 May not be relevant, but are any other files open at this point? > cbm_write( to ch.15 "p,96+2, rec#n, 1" ) <--- Position to rec #n > cbm_read( from ch.2 to buffer ) <--- Returns '0' bytes (!), but _oserror == > 0 > cbm_read( from ch. 15 to buffer ) <--- buffer has '70, ... ' error message > > I can perform this exact series of steps from BASIC and all is well > (provided I specify valid position). [...] > The original code was using a value of 127 for error channel address. This > seemed very odd, particularly since I cannot locate any obvious place where > 127 is opened in the first place. I'm a bit unclear on your meaning here. After some thought, I conclude that by "error channel address" you mean the Kernal "Logical File Number" that CBM Commander opens to the error channel -- the one you summarized as "file # 15" in your own exploration of the problem. Is that correct? If so, that is indeed quite puzzling. I am aware that Kernal LFNs are 8-bit values, and that any LFN greater than 128 (i.e., with the high bit set) causes a CRLF sequence to be emitted at each line break, rather than the usual plain CR. I also vaguely recall something problematic about using abnormally large values. Something about a glitch in certain Kernal revisions? Or were certain values reserved for an obscure purpose most people never read up on? I may well be completely misremembering both of those. If, in the other hand, your use of "error channel address" was a bit more literal and the number 127 is actually being passed somewhere to be used as the drive's secondary bus address... well, that'd be a really good trick, fitting a 7-bit value into a 4-bit field. *grin* Please clarify? G.Received on 2020-10-11 07:00:03
Archive generated by hypermail 2.3.0.