Use Cursors To Scroll Text Use Cursors To Scroll Text Tape To Disc Transfer. Tape To Disc Transfer. Messages sent by Albert Schofield. Still being Compiled. ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ISSUE 33 ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, To: 999 (all members) From: K3H (Albert Schofield ) Subject: Tape to Disc. Chris has suggested that I write some articles on my pet subject which I will call Tape to Disc on the BBC Model 'B' Some of you may have started, like myself, with just a cassette based machine and later had a DFS fitted. Well, let us suppose that you have just switched your machine on and can't wait to get your programs on to disc. So you load your program, which is an ordinary basic program, from cassette, type *DISC, and in no time at all it is on disc. Then you run it. If it is a fairly short program it may work perfectly. If it is a fairly long program then it will probhably stop with an error message usually BAD MODE, the mode being bad because there is not enough memory available. The reason for this is because the DFS uses a large slice of memory. On a cassette based machine page is normally at &E00. You can check this by typing PRINT~PAGE. On a disc based machine page is much higher usually &1900. However, you can claim some of this memory back. If the program does not use any file handling commands such as OPENIN etc. and most games don't, then you can lower page to &1100. So type PAGE=&1100 and run your program again. If it works OK then add the following line to the beginning of your program:- 1IF PAGE<>&1100 THEN PAGE=&1100:CHAIN "PROG" Put the filename of your program in place of PROG. Then when you run your program in future it will automatically set page to &1100. But if your program still gives error messages with page at &1100 then you will have to download it to &E00. To do this add the following lines to the beginning of your program:- 1CLS:VDU23,1,0;0;0;0;:PRINTTAB(8,10) CHR$(131)"Downloading...." 2*FX3,2 3*KEY0 *TAPE|MD%=PAGE-&E00:FORL%=PAGE TO TOP STEP4:!(L%-D%)=!L%:NEXT:PAGE=& E00|MOLD|MDEL.1,5|M*FX3,0|MRUN|M 4*FX138,0,128 5END The downloader deletes itself. Your program will then be in memory exactly as if you had loaded it from cassette. You can create an ASCII version of this downloader and save it to disc. Then with your program in memory the downloader can be *EXECed on to it and saved to disc. See page 402 of the User guide to do this. But first make sure that the first line of your program is not numbered less than six. If it is RENUMBER your program or the first lines will be overwritten. That's all for this month. I hope some of you have found it useful. Next month I will deal with machine code programs. ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ISSUE 34 ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, To: 999 (all members) From: K3H (ALBERT SCHOFIELD) Subject: TAPE TO DISC FOR M/C PROGRAMS Most games are in several parts, each part chaining or *RUNning the next. If a program is chained then it is BASIC. If it is *RUN or *LOADed it is machine code. Let us suppose we have a three part game on tape. The first two parts are in BASIC and the last part is machine code. The first two parts can be just loaded type *DISC and then saved. If the file names are more than seven letters long then they will have to be shortened to seven letters, the maximum allowed by the DFS. To get the M/C program on to disc type *OPT1,2 (RETURN) then type *LOAD""1900 (RETURN) to load the M/C program from tape. When the program is loaded you will have four sets of numbers after the filename. Ignore the first four numbers or letters in each set. The first set is the number of blocks and can also be ignored. The second set is the length of the program. The third set is the load address and the forth set is the execution address. Now type *DISC. To save the program to disc type *SAVE"filename"1900+length execution load Put the proper filename in and the three sets of numbers where indicated. &1900 was used as a temporary address for loading an saving and is discarded when the program is saved. The three parts are now on disc so chain the first part. You may get an error message either FILE NOT FOUND or BAD FILENAME. This means that the first part CHAINS"". A null string will not work on the DFS or the first part is using a filename more than seven letters long. Alter the first part to chain the filename of the second program. The second part may also need altering. If the load address of the third part is &1100 or more, the program may now run but it will probably be less so it will have to be downloaded. The following short relocator will do this:- 10 *KEY0 *LOAD "filename"1900|M *TAPE|MFOR T%=0 TO &length STEP 4: T%!&load =T%!PAGE:NEXT|M CALL&execution|M 20 *FX138,0,128 30 END Put the filename, length, load and execution addresses in where indicated. Some DFSs include relocating utilities. The Watford DFS has the commands *MRUN and *MLOAD which will do the relocating. If you have the BEEBUG DISC MASTER this has an excellent move down routine which tags a small machine code on the end of your program for either machine code or basic programs. That's all for this month. Next month I will deal with the problem of LOCKED programs. ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ISSUE 35 ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, To: 999 (all members) From: K3H (ALBERT SCHOFIELD) Subject: TAPE TO DISC ON THE BBC'B' First I would like to deal with MR. Gallagher's problem which he is having with 'MAGIC MUSHROOMS'. It is basically a tape to disc problem as your disc version has originated from tape and has not been fully transferred. Just over half way through the main file there are two references to TAPE. Use a sector editor to change these to DISC and you will then be able to save and load screens to disc. This month I am going to deal with the problem of LOCKED files on tape. A LOCKED file on tape can only be *RUN. It cannot be *LOADed or *DUMPed. It cannot therefore be transferred to disc. However there are plenty of utilities for unlocking files on tape and locking them again. Once unlocked they can be transferred to disc in the usual way and most files work just as well unlocked as locked. On the other hand some files when unlocked will not work and locking them on disc is of no use as this is a different method altogether. So what can be done ? If you have sideways ram the ROM FILING SYSTEM is very similar to the CASSETTE FILING SYSTEM, so the file can be put into a ROM image, locked once again and will work from the RFS. A short loader program can be used to load the ROM image and *RUN the locked file something like the following:- 10 *KEY10 *ROM|MPAGE=&E00|M*OPT1,2|M *RUN filename|M 20 ?&FF34=0:*LOAD filename 8000 30 CALL!-4 The first line programs the break key to enter the RFS. The OPT command lets you see the file loading and then the locked file is *RUN. The second line selects the rom bank to be used, in this case bank 4. Alter the 4 for any other bank. Then the rom image is loaded from disc. Use the filename you have chosen. The last line 'presses' the break key which initialises the rom image and *RUNs the locked file. That is one way of doing it. But what if you do not have SWR. There is another and better way but not as simple. The reason the locked file will not work when unlocked is because the execution address is a false one so if you can find the true execution address then the file will work as normal without having to be locked. But how do you find it ? It is not always easy. It is in the file somewhere and in reverse order. In some acornsoft games such as VOLCANO the true execution address is the last two HEX numbers on the file in reverse. In the case of VOLCANO the last two HEX numbers are A0 and 44, therefor the true execution address is &44A0. Last of all there is another type of locked file which when unlocked will not work and when it is locked again it still will not work so I can only assume that it is locked originally in some special way. That is why if this type of file is backed up with a tape copier which has unlocking facilities, the resultant copy will not work. So with this type of file the SWR method cannot be used. The only way is to find the true execution address. With this type of file there is usually a short machine code loader which contains the true execution address. The file can also be *DUMPED and various addresses tried but unless you are an expert in machine code it can be a long task. Next month I will be discussing various tape to disc utilities. ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ISSUE 36 ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, To: 999 (all members) From: K3H (ALBERT SCHOFIELD) Subject: TAPE TO DISC ON THE BBC'B' There are many types of tape to disc utilities, some on disc, some on ROM. Some are quite good but tend to be fairly limited. For instance they cannot cope with games that are loaded as a continuous stream of data. This is where the utilities which save the whole of computer memory come into their own. The best must be REPLAY as this will transfer just about everything but this requires quite a bit of extra hardware and specially formatted discs. However there is another memory saver which only requires a single bank of SWR and that is SNAPSHOT which, I beleive is available from 8-BIT. This is an excellent tape to disc and disc to disc utility. It will not cope with everything but can transfer most. I originally obtained it from TELESOFTWARE and consists of three files. One is a text file with the instructions. When a program is saved to disc it is saved as two files. One is memory from zero to &1400, the other is memory from &1400 upwards. The command used to reload the saved program is *RESTORE. I have found that the best way to reload from disc is to save the ROM image. Have this on a disc with the two memory files. Then all that is needed is a short loader program something like the following:- 10*KEY10 *RESTORE|M 20?&FF34=0:*LOAD 8000 30CALL!-4 This will load in the ROM image and give the *RESTORE command. If the game has a page of instructions it can be saved on to the disc as normal and the loader program incorporated into it. I have found that SNAPSHOT can be useful in another way. Sometimes a decoded file or a file loaded in as a continuous stream of data can be retreived from the two memory files and used independently of SNAPSHOT. The ROM image takes up rather a lot of space on disc but this can be reduced to &500 and will still work. More next month. ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ISSUE 37 ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, To: 999 (all members) From: K3H (ALBERT SCHOFIELD) Subject: TAPE TO DISC ON THE BBC"B" Sometimes when a game or utility etc. which may be made up of several parts has been transferred from tape to disc and then run, one or two parts may load and then suddenly the searching message appears on the screen and the computer is back in the tape mode. If the offending part is in basic then you will have to list it and look for *T. or *TAPE and eliminate it. Or it may be *FX140 which is the cause or even something like:- FOR N%=6 TO &3F: N%?&200=N%?&D940:NEXT. So a bit of detective work is required to isolate and eliminate the guilty section. Also the lines containing the statements may have been made unlistable so you may need to use *DUMP to find it. In this case you will have to use a sector editor to remove it. But what if the offending part is in machine code. With this you will have to *DUMP it and seek out the following sequence of hex numbers:- A9 8C A2. 8C is the OSBYTE CALL for TAPE (See page 434 of the user guide) If it is a long program it can be a lengthy search. Use a sector editor to eliminate the 8C. Replace it with a space (20) then all should be well. If the next part has to be loaded via sideways ROM then the 8C could be changed to 8D and then the computer will search in the rom filing system. 8D being the OSBYTE CALL for ROM (See page 165 of the advanced user guide) I am sorry MR. GALLAGHER (4MD) that my information regarding MAGIC MUSHROOMS did not work for you. Your version of the game must be different to mine. However, this article should solve your problem. Let me know how you get on. As a last resort you could send me a copy of your version and I would try to sort it out for you or I could send you a copy of my version. And finally thanks ROY (20G) for the bouquet. More next month. ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ISSUE 38 ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, To: 999 (all members) From: K3H (ALBERT SCHOFIELD) Subject: TAPE TO DISC ON THE BBC"B" In a previous article I wrote about the possibility of false execution addresses. It is also possible to have false load addresses. The file information is usually obtained by the use of *OPT1,2. The use of *OPT1,2 will obtain the information from the last block of the file. In some cases the last block of the file has been altered to give a false load address. In fact some files have a different load address in every block but the load address in the first block must be the correct one. To obtain the file information from the first block, catalogue the file from cassette and as soon as the first block appears on th screen as "PROG 00" (PROG being the file name) press ESCAPE. Then type:- PRINT ~!&3BE . The true load address will then be shown. Another way of finding the true load address of any file would be to load the file from cassette and then save it using SNAPSHOT. Then *DUMP the memory files so obtained to see where the relevant file starts. If you find that your transfer of any files from tape to disc does not work for no apparent reason it is always worth while checking the load address from the first block to see if it is the same as the one obtained by using *OPT1,2. More next month. ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ISSUE 39 ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, To: 999 (all members) From: K3H (ALBERT SCHOFIELD) Subject: TAPE TO DISC ON THE BBC"B" Most of the newer games for the BBC micro on cassette are in quite a number of parts. Some of these games can be transferred to disc and will run without alteration at all provided that all the parts load at no less than &1100. If the last part loads at less than &1100 then it can be downloaded and the game will run perfectly even though the computer ends up in the tape mode. But if a section has to be downloaded before the last part has been reached then there is a problem as the DFS can not be re-entered without corrupting memory. The way to overcome this is to put the last parts into a rom image. They can then be reloaded from the rom filing system with page below &1100. A short loader program can be written to load the rom image or images and then run the first part of the game as I described in a previous article. In last months article where I dealt with the problem of machine code programs that revert to tape I may possibly have caused some confusion by the way the article was set out. So, to recap, the three pairs of hex numbers to find are A9 8C A2. The 8C should be replaced with a space (20). I recently came accross another method which is used to make a program revert to tape in OMEGA ORB. This game is in eight parts and they all load at &1100 or over so no downloading is involved. Five of the parts have an execution address of B80. At this location there is a tape routine which causes the problem. This routine is placed there by the third section "OMEGA2". This section is the loader and is really a basic program posing as machine code. So edit this using a sector editor. The first statement is !2944=&A28CA9. You will see that this contains the three pairs of hex numbers I mentioned earlier but in reverse order. Also 2944 is the decimal equivalent of B80. So again alter the 8C to 20. Then carry on shortening the file names to the seven characters that you have used to save them to disc. The game should then run from disc without any problems. If anyone would like any help transfering to disc a game or utility please let me know either through the 8-BIT disc or drop me a line. My address is 46 FIR St. NELSON. LANCS. BB9 9RG. More next month. ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ISSUE 40 ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, To: 999 (all members) From: K3H (ALBERT SCHOFIELD) Subject: TAPE TO DISC ON THE BBC'B' Transferring files from tape to disc is usually a simple task. Utilities exist for doing this and the computer can be left to get on with the job. Getting the files to work on disc is when the problems arise. However sometimes transferring files from tape to disc can be a problem if the file is exceptionally long as in some adventure games. Even with page at &1100 the file tends to spill over onto the screen when loaded, and when saved to disc may have bits of the DFS rom in it which means that it will not work properly. A way round this problem is to transfer one block at a time. The following program will do this. 110 *TAPE 120 IN=OPENUP("") 130 *DISC 140 OUT=OPENOUT("filename") 150 *TAPE 160 REPEAT 170 C=BGET #IN 180 *DISC 190 BPUT #OUT,C 200 *TAPE 210 UNTIL EOF#IN 220 CLOSE#IN 230 *DISC 240 CLOSE#OUT Enter the filename for the file on disc at line 140. If the file should happen to be locked add the following lines. 10 FOR pass%=0 TO 3 STEP 3 20 P%=&70:[OPT pass% 30 PHP:PHA:TXA:PHA:TYA:PHA 40 LDA &3CA:AND #&FE:STA &3CA 50 LDA #0:STA &3C7 60 PLA:TAY:PLA:TAX:PLA:PLP:RTS 70 ]:NEXT 80 ?&220=&70:?&221=0 90 *FX14,4 The file will be transferred to disc automatically (providing you have motor control) with no more than one block in memory at any time. With the complete file in disc it will then be necessary to set the load and execution addresses of the file to the correct values. The following program will do this. 10 OSFILE=&FFDD 20 DIM PARAM 18,NAME 8 30 $NAME="filename" 40 !PARAM=NAME 50 PARAM!2=& 60 PARAM!6=& 70 X%=PARAM MOD 256 80 Y%=PARAM DIV 256 90 A%=2 100 CALL OSFILE 110 A%=3 120 CALL OSFILE Enter the correct filename at line 30. Enter the correct load address afte the '&' at line 50. Likewise enter the correct execution address at line 60. More next month. PRESS SPACE PRESS SPACE