Posted: Sun Nov 9, 1986 6:35 PM PST Msg: MGIG-2484-3940 From: CHHU To: CHHU Subj: [3]<--[12]: DISCOPY Last week I did some 3.5" disc copying for the first time (!) so I dug out MCOPY71B from Swap Disc 85. While it was an interesting exercise, I would hope to delegate the job in future, if not to someone else, then at least to my sub concious. DISCOPY is a first attempt to automate MCOPY71B. DISCOPY: AUTOMATIC HP-9114 DISC DUPLICATION FOR HP-71B Power up the loop with one more 9114 than copies wanted (max 15 copies) and CALL DISCOPY. After keying a response to the prompt for the number of copies wanted (not all drives in loop need be utilized), and an indefinite period of 5 or 10 seconds while the 9114s (usually) whirr and blink and click around, control of the program passes to the DRIVES (press any key except ATTN to abort the process at any time before actual copying begins). The operator is prompted to load the slave drive(s) first, then the master. Discs can be put into any drive in any order. If the discs are already in situ then just briefly eject and re-insert them when prompted. As each disc is loaded its volume label, if any, will be displayed. If a disc is unitialized it will be reported as ".Device Not Ready" and flagged for automatic formatting (which is done before copying begins). When all discs are loaded control returns to the keyboard for an OK from the operator to proceed with formatting and/or copying to the slave discs. Error trapping during set-up is fairly extensive and most operator errors up to copy start cause the program to abort but there's no check yet on the copies or copying process. Hasn't been tested much, and not at all on >1 slave drive. It seems to work OK on two drives, and SHOULD go OK on more (!?!&c), but I haven't met enough so far to try. The two subprograms called can be used in a variety of disc management routines. WAIT waits on a massmem medium replacement and returns with the total Number of drives of the device type specified by D$ on the loop, and sequence # of the One on which a medium is replaced (O returns as zero if a keypress aborts). MEDID is not only a serious attempt at giving structured programming bores terminal apoplexy, but also returN$ the volume label on the device specified by D$ if Flag 0 is clear (or replaces it with N$ if Flag 0 is set). MEDID was kludged together a couple of years ago to get a q&d volume label access, and like so much else in my CMOS, has somehow just never gotten unkludged. In the DISCOPY subprogram: 10 sets some status & saves the IS table 20 gets input for # of copies required 30-40 count the 9114s & offload the silly billies 50 offers vague advice 60 nudges drives 70 prompts to load slave drive(s) 80-90 negativises sequence #s to identify unformatted discs 100 prompts to load master drive 110 rejects unformatted masters 120 last orders please 130 offers slightly more precise advice 140 converts slave 9114 sequence #s into IL addresses 150 ditto for master 160 listens the drives with unformatted discs 170 formats them 180 offers slightly premature advice, hopefully 100% precise 190 resets selected devices 200-220 do an MCOPY71B using the selected drives 230-250 provide various exit messages 260-270 restore the IS table and display the final score 280-290 are a subroutine that hangs around waiting for things to finish 300 begins a subroutine that hangs around waiting for things to start 310 offloads the smarty billies 320 gets inserted medium's volume-label/format-status and ectoplasm 0010 SUB DISCOPY @ S$=PEEK$("2F78D",21) @ STD @ DELAY 0,0 ! + uses Flags 0 & 63 0020 DISP @ INPUT "# of slave 9114s? ","1";C @ C=INT(C) 0030 IF C<1 OR C>15 THEN 20 ELSE N=0 @ N$="IL " @ ON ERROR GOTO 250 0040 N=N+1 @ IF DEVADDR("HP9114("&STR$(N)&")")>0 THEN 40 ELSE IF N-2"; @ GOTO 450 ELSE DISP D$ @ N$ =R$[3] @ GOTO 470 0420 S=SPOLL(A) @ IF BIT(S,5) THEN 420 ELSE IF NOT S THEN RETURN 0430 N$="#%16Ft" @ DISP MSG$(255034) @ END 0440 SEND LISTEN A MTA DDL 4 DATA 0,0 UNT UNL @ GOSUB 420 @ RETURN 0450 N$=UPRC$(N$)[1,6] @ R$[3]=(N$&" ")[1,6] @ GOSUB 440 0460 SEND UNL LISTEN A MTA DDL 2 DATA R$[1,7] END NUM(R$[8]) @ GOSUB 420 @ DISP R$[3] 0470 SEND LISTEN A DDL 7 UNL @ GOSUB 420 @ END End of File Action? Command? READ 18 Posted: Sun Nov 9, 1986 7:38 PM PST Msg: GGIG-2484-4002 From: CHHU To: CHHU Subj: H.Y.J.R. Bake John - (or Sam, Joseph, whoever) Is there a 71 LEX function around which checksums a specified file? (I mean, with token allocated, etc?) A method of automatically detecting changes in specified files is a very big chunk of what's required to make a reasonably transparent portable/base mass memory management system work. Currently I use a semi-manual BASIC routine and a key definition kludged onto the text editor to run a reasonably automatic media manager, but an absolutely no thought required version would be possible using file checksumming. I might write one myself if there isn't. (Like I might clean my desk if I get a tuit). Is there any use for such media managing code in/on CHHU ROM/disc/tape? Michael - Lines 260-270 of the copy routine I just posted you should read 260 SEND UNT UNL @ POKE "2F78D",S$ @ POKE "2F7B1","7" @ RESTORE IO 270 DISP N$ @ BEEP 440,1 @ END Previously posted was the wasteful version (for people with time and memory to flaunt). Nick [12] Posted: Mon Nov 10, 1986 4:52 AM PST Msg: DGIG-2484-4373 From: CHHU To: chhu Subj: to Brian from John Baker Dear Brian, Let me take the liberty of addressing your comments regarding Jim DeArras' HP71 cross asseembler. He is going to make it available through CHHU in the near future. The current version has several nasty bugs in it which are being fixed. As soon as that is done, it will be released. Beleive me, you cannot possibly be any more anxious to have it running than I am. I have a number of assembly files which take 2-3 xurs to assemble using FORTH. Rest assured, as soon as the bugs are fixed, you will be the first to know. As to versions, there is only one version. It will run on the HP110 or any pc clone/compatable. What IS different is the method of transfering the compiled code back into a HP71. As the binary image produced by the assembler is not the same as the binary image loaded via HPILLINK, HPILLINK cannot be used to transfer the code. I am currently working on several pieces of code which will allow transfers to occur and expect them to be available concurently with the debugged cross assembler. One planned piece is a 'link' type piece of code to operate on the binary image in the pc filechain which will convert it to an image compatable with HPILLINK. Jim also has several download utilities for both pc clones and the 110. They operate at 9600 baud over RS-232. Regards, John Baker [618] . Action? Command?