Dear RISC User,
I have recently upgraded to the Archimedes from a Master 128. I have a dual 5.25" disc drive which I used with the Master, and I would like to connect this to the Archimedes, though I am not sure what is involved. I notice that BEEBUG sell a Disc Buffer - can you explain what this does, and will I need one?
Martin Featherstone
Any 5.25" disc drive must be fitted externally to the Archimedes, and must include its own power supply (in other words plug directly into the mains). Unfortunately, the disc interface in the Archimedes cannot directly drive the length of cable needed to connect an external drive, and operation of the drive would be unpredictable if this was attempted. Therefore, a buffer is needed to boost the signals sent from the Archimedes to the drive, and this is exactly what the BEEBUG unit does. The buffer itself consists of a small circuit board which is easily fitted inside the computer (without the need for a backplane), and which has a socket on the back to connect up to four external drives.
As well as buffering the signals, the BEEBUG buffer performs a number of other functions. In particular, it allows the external drives to be double-stepped so that 40 track discs can be read in 80 track drives, and it also generates certain signals which are needed by the Archimedes but which are not provided by some older disc drives.
Once the external drive is connected, any ADFS format discs from the Master can be read directly. If, however, you want to read DFS format discs you will also need the BEEBUG DFS Reader which is a program designed to read files from a DFS disc and transfer them to an Archimedes disc. You can also of course use the 5.25" drive simply as an extra drive for the Archimedes.
For more details of both the BEEBUG Disc Buffer and the DFS Reader refer to the current retail catalogue.
David Spencer
Dear RISC User,
In a number of recent programs in RISC User, the word "OSCLI" has been used in a program line which saves or loads a data file. Do I need to use this to load and save blocks of RAM, and if so, how does it work?
Brian Kerr
The use of OSCLI for loading and saving blocks of RAM is certainly convoluted. But fortunately there is a simpler way which makes use of the SYS call "OS_File". This is implemented both on Arthur 1.2 and on RISC OS, and allows variables to be used for filename and addresses where necessary, but avoids the convolutions inherent in the other method.
To load a file use:
SYS "OS_File",255,<Filename>,,1
The "1" at the end of the call tells the filing system to load the file at its load address.
To load a file at a given address the command is:
SYS "OS_File",255,<Filename>,<address>
For example:
SYS "OS_File",255,name$,buffer%
would load the file called name$ into RAM at the address held in buffer%.
To save a file use:
SYS "OS_File",10,<filename>,<filetype>,, <start>,<end>
This call additionally sets the file type of the file (for details on file types, see Volume 2 Issue 4 page 42). To give an example, suppose you want to save a block of data held at buffer%, and of length len% to a file called MyFile, and use a file type of &FFF (i.e. ASCII data), you could use:
SYS "OS_File",10,"MyFile,&FFF",,buffer%,buffer%+len%
These calls are reasonably easy to use, but you must remember that the call name ("OS_File") is case sensitive ("OS_file" will not do), and be careful with the commas: they are vital.
Lee Calcraft