Archimedes 6502 Emulation: Application Note ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Name: 0340011 Version: 0.02 History: 0.01: Undated : started. 0.02: 15-Feb-89: updated for release on SID This application note addresses itself to the issue of portability of software written for the BBC range of 6502-based microcomputers onto the Archimedes microcomputer, using the latter's 6502 Second Processor emulator. The term BBC is used in this document to refer to the following 6502-based microcomputers: the BBC Model B, B+, Master 128 and Master Compact. Features of BASIC and/or 6502 machine code are considered, and the possible consequences when run with the emulator invoked. The 6502 emulator is referred to in this document as 65Arthur. In addition to the 6502 emulator, a program is referred to, *BBCrun, which is designed to support the emulator when attempting to run programs written for the BBC microcomputer. This program is available from RESOURCE (Tel: 0302 63800/63784) as part of the 'BBC to ARM: Utilities' package. The 6502 emulator, *BBCrun and the Arthur Machine Operating System are subject to continuous development and improvement. All information of a technical nature in this note is given by Acorn Computers Limited in good faith. However, it is acknowledged that there may be errors or omissions in this note or in the products it describes. Acorn Computers Limited can take no responsibility for the behaviour of Third Party software used with Acorn equipment. PROGRAMMING FEATURES AND THE 6502 EMULATOR The Archimedes Operating System, 'Arthur', is similar to the MOS of the BBC range of microcomputers, so that a reasonable degree of portability will be conferred on software packages for the latter, as long as the legal interfaces provided by Acorn have been adhered to. However, the hardware is different: the disc filing system is ADFS and not DFS, and together with packages that tweak the system, it is inevitable that some BBC microcomputer packages will not run on the Archimedes microcomputer even with the emulator invoked. These packages will need modifying if they are required to run on the Archimedes microcomputer. Problems arising at the code level have been classified into the following areas, and are dealt with in sections: A 6502 machine This includes code assembled from BASIC at run code time, or object code loaded and called. D Disc filing In general, this will be DFS-specific code which system will fail on the ADFS, which is the disk filing system used by the Archimedes microcomputer. C PAGE, HIMEM Assuming values of these pseudo variables, normally and LOMEM associated with some patch to get round RAM shortage in an expensive graphics mode. B Direct memory A multitude of sins, some of which can't access be got round with the emulator. E Hardware Accessing hardware directly. Note that some BBC micro hardware will become available as a podule. E Firmware Calling undocumented routines in the firmware. B Changes in the Primarily where the BBC MOS definition assumed a Operating 16-bit address space. System The following scheme is used to indicate the likely effect of each feature: A Indicates that 65Arthur will get round a particular feature. B Indicates that 65Arthur may solve the problem. C Indicates that *BBCrun will probably get round a particular feature. D Indicates that *BBCrun may solve the problem. E Indicates that a feature is likely to prove an intractable problem. CONTENTS A 6502 MACHINE CODE D DISC FILING SYSTEM E Direct access of the disc controller chip E OSWORD calls used to access a DFS disc D Assumptions about DFS workspace C Assuming DFS format when using OSGBPB D Difference in directory structure D Disc filing system *COMMANDS E Illegal characters in filenames C Filing system type C PAGE, HIMEM AND LOMEM C Setting PAGE C Relocation C Raising HIMEM C Lowering HIMEM C Raising LOMEM B DIRECT MEMORY ACCESS D E Peeking/poking in system workspace D Assuming functions of particular Pages C Page C E Page B E Envelope storage, &8C0-&9BF B Using 'safe' areas as extra storage A User workspace &70-&8F E HARDWARE E Timing E Sideways RAM/shadow memory E Screen memory E Reading/writing screen memory D Loading/saving picture files E Screen dumps E Disc controller E Other hardware E FIRMWARE E Undocumented MOS routines E BASIC ROM routines E Assumimg ROM extensions B CHANGES IN THE OPERATING SYSTEM Key: A Indicates that 65Arthur will get round a particular feature. B Indicates that 65Arthur may solve the problem. C Indicates that *BBCrun will probably get round a particular feature. D Indicates that *BBCrun may solve the problem. E Indicates that a feature is likely to prove an intractable problem. 6502 MACHINE CODE - A This is handled by the 6502 emulator, but the same considerations outlined in this document apply here as with BASIC code - e.g. that the screen memory is not peeked or poked directly (which rules out many arcade-style games). Trapping direct screen access with the emulator is not feasible, since it would slow a program down by as much as a factor of ten in comparison to running the same code on a BBC microcomputer. DISC FILING SYSTEM - E ADFS is the standard disc filing system for the Archimedes microcomputer, using 3.5" disks at the entry point of the range, whereas the usual disc filing system for the BBC Model B is the DFS, on 5.25" discs. Thus, you will encounter problems in porting packages written for the BBC B, B+ or Master series where DFS-specific code will fail on the ADFS. Problems may arise in the following areas: Direct access of the disc controller chip - E This would normally only be associated with copy protection systems. OSWORD calls used to access a DFS disc - E OSWORD=&FFF1 A refers to the Accumulator contents on entry: A=&7D Read the number of times the disc has been written to. A=&7E Read the disc size (normally 40 or 80 track). A=&7F Disc controller commands, using a parameter block to communicate with the disc controller chip. Examples of use include: with A=&7F with the parameter block set to read the disc catalogue (first two sectors of a standard DFS disc). or using this call for fast read/write operations. or associated with protection systems. These calls are not supported by ADFS and so will fail. The Archimedes ADFS no longer supports the following OSWORD calls for double-density disc formats: A=&70 Read status info. A=&72 Read/write data. A=&71 Read free space. A=&73 Report error. Assumptions about DFS workspace - D Some application programs make assumptions about the contents of memory between &E00 and &1900, used as workspace by the DFS on the BBC Model B and B+. Examples include: C peeking Page E to get at catalogue information. A using one or more Pages in this range for data storage when the application program will not need them for file I/O. Assuming DFS format when using OSGBPB - C OSGBPB=&FFD1 For example, expecting the filenames to be at intervals of 8 bytes when reading the names in the current directory (OSGBPB with A=8). Likewise, displaying ADFS filenames on screen can ruin display windows, when filenames of 7 characters or less have been assumed. Difference in directory structure - C Unlike the DFS, the ADFS has a tree-like, or hierarchical structure and this can cause problems for packages assuming the DFS. Imagine an application package for the DFS which has data files in directory D and BASIC programs in directory B. The package uses the following sequence: *DIR D PROCaccess_some_data *DIR B PROCCHAIN_in_NEXT_BASIC_program This will crash on ADFS, since the filing system will expect B to be a sub-directory of D. DFS flat or heterarchical organisation. $....D....B....etc. ADFS nested or hierarchical organisation. $ root directory * D * B * subdirectories * * * This may be a problem with any filing system command, called from an application, which is common to DFS and ADFS and which requires the file specification as argument. The relevant commands are: *COPY *DELETE *DESTROY *LIB *RENAME *DIR Disc filing system *COMMANDS - D In addition to those associated with differences in organisation of the filing systems, covered in the previous section, other problems may arise where the syntax or arguments of a common command are different. For example: *ACCESS Finally, the most likely eventuality in this category is where a command for DFS doesn't exist for ADFS, in particular: C *DISK (often used in f0 definitions in association with relocation) or does exist but will have different consequences, for example: C *DRIVE This may arise in an application which assumes two disc drives (e.g. using the second drive for a data disc), and will fail on a single-drive ADFS system, unless ignored at run time. Illegal characters in filenames ADFS is more stringent than DFS as regards permissible characters, and will not allow the incorporation of the following in filenames: & $ % . ^ \ | @ <> Filing system type OSARGS=&FFDA, Y=0, A=0 This call, with the registers set up with these values, returns the current filing system. Application programs may check for returned values of 4 (DFS) and 5 (Net) only, assuming any other values indicate the cassette filing system. This will fall foul of the ADFS, which returns 8. PAGE, HIMEM AND LOMEM - C This category is concerned with assumptions or manipulations made with the BASIC pseudo variables PAGE, HIMEM and LOMEM - almost all of which are associated with techniques used by programmers to grab the maximum space for BASIC code in the variety of firmware environments in which a program may find itself. There is a great variety in this area, and the usual problem will be assignment of particular BBC addresses to these pseudo variables. In general, the 6502 emulator will handle relative changes (e.g.HIMEM=HIMEM-&100). The command, *PAGE , is provided by the 6502 emulator so that the user can set PAGE to a requisite value before initialising BASIC (*BASIC) and running a BASIC program. Setting PAGE - C A software package may set PAGE to a requisite value before running a BASIC program, for example: IF PAGE>&1200 THEN PAGE=&1200:CH."Next" Relocation - C Relocating a program in memory, before setting PAGE, and executing an OLD:RUN. The 6502 emulator may cope with both these, but currently it sets PAGE=&800, for Second Processor compatibility, and the application program may not be expecting this (e.g. relocating anyway, and overwriting itself!). Using the emulator and setting PAGE=&1B00 before running the package should be satisfactory in many cases, but in the second category, relocation as far as &E00 may involve selecting the cassette filing system and poking into Zero Page, which brings further problems. Raising HIMEM - D The 6502 emulator will in general cope with this, but it is likely that the application program will come unstuck due to an associated feature. An example is pushing up HIMEM in a high resolution graphics mode, and redefining the screen with fewer lines etc., in order to claw back some memory for a BASIC program. Lowering HIMEM - C This would be to provide some cache memory, for example: HIMEM = HIMEM - &100 Raising LOMEM - C Again, to provide cache, perhaps to hold a machine code routine or provide space for BASIC overlays, both of which should be handled by the emulator providing the code does nothing untoward. DIRECT MEMORY ACCESS - B,D This covers all those situations where memory is addressed directly except where the address is that of a documented Operating System routine (e.g.OSBYTE=&FFF4). Application programs may have used direct addressing: for increased speed to find some extra space as a result of assumptions made about the use of particular areas of memory to get at the hardware to use (undocumented) routines in the firmware. Hardware and firmware are covered in later sections. What follows covers features arising from programs looking for extra space or making unwarranted assumptions about the memory map, and is concerned with memory below OSHWM (i.e. PAGE in BASIC). Although examples given are in BASIC, the principles apply as well to machine code. Peeking/poking in system workspace - E e.g. mode%=?&355 to find the current screen mode The legal alternative is to call OSBYTE, with A=&87, which returns MODE in Y. (BASIC V provides the MODE function for this). Assuming functions of particular Pages - D C Page C Loading graphic character definitions directly into Page C. Likewise, saving character definitions in this way. *SAVE chars &C00 &CFF E Page B Loading soft-key definitions directly into Page B. Likewise, saving soft-key definitions in this way. *SAVE f0Keys &B00 &BFF E &8C0 Envelope storage. - &9BF Loading sound envelopes into &8C0-&9BF. Saving envelopes from this area. Using 'safe' areas as extra storage - A This may be to store data or locate machine code, normally in Page A or Page 9. Pages C and B may also have been used, if the program did not require user-defined characters and soft-key definitions respectively. In addition, applications exclusively in machine code may have used the language workspace, Pages 4-7, which is quite legal in terms of the 6502-based BBC range of microcomputers. Refer also to the section under Disc Filing System entitled Assumptions about DFS workspace. User workspace &70-&8F - A 6502 BASIC (i.e. BASIC 1-4) reserves this area for the user out of its Zero Page allocation (&00-&8F for the current language). Thus, applications using this area from BASIC will be supported by the emulator, as will machine code applications. However, other languages have reserved more of this language workspace for user applications. HARDWARE - E Timing - B The RISC architecture is orders of magnitude faster than the 6502-based systems, but the emulator slows execution speeds down nearer to those of the 2MHz 6502 microprocessor. BASIC 2 will execute slower with the emulator invoked on the Archimedes microcomputer than on the Model B, as indicated by standard bench-marks. However, since many application programs' speed are limited by I/O (e.g. screen drawing), and this will go an order of magnitude faster in some cases, this will tend to compensate for the longer calculation and data handling of the emulator on the Archimedes microcomputer. Timing mis-match will be most evident where application programs have used timing loops, rather than accessing the pseudo-variable TIME. e.g. FOR I%=0 TO 1000:NEXT to provide a delay. Sideways RAM/shadow memory - E Programs assuming the existence of sideways RAM or shadow memory currently will fail with the emulator invoked. Screen memory - E E Reading/writing screen memory Reading and writing directly to the screen, including using OSWORD with A=5/6, rather than using the appropriate VDU command (or equivalent such as PLOT). For example: MODE 1:FOR I%=&3000 TO &5800 STEP 4:!I%=&F0:NEXT D Loading/saving picture files For example: in MODE 4 *SAVE screen 5800 8000 E Screen dumps Those that peek screen memory directly. Disc controller - E As mentioned in the section called Disc Filing System, directly writing to the floppy disc controller chip (Intel 8271 or Western 1770/1772) is not possible (as are equivalent DFS OSWORD calls). For example: ?&FE82=1:?&FE82=0 to reset Other hardware - B The BBC hardware chips are not part of the standard Archimedes architecture, but an I/O podule will become available, with the 6522 VIA etc.. Thus, programs which access the User port, for example, should run with the emulator invoked with this podule installed, provided that the documented calls to the BBC hardware have been used. To summarise, any direct access of the hardware by peeking/poking FRED, JIM or SHEILA will fail, whereas using the OSBYTES 146-151 will in general be supported. FIRMWARE - E Any software using undocumented routines in the firmware is likely to have already experienced problems of portability across the BBC range, being effectively tied to a particular firmware issue. Undocumented MOS routines - E These are sure to be different. BASIC ROM routines - E In general, this will be programs which use the mathematical routines in the BASIC ROM, and probably are assuming BASIC 2. e.g. JSR &nnnn \BASIC SIN function This is, of course, illegal and depends on the address of the routine staying the same. Assuming ROM extensions - E Software relying on the presence of additional ROM's for the BBC microcomputer will fail. Assuming the DFS ROM is dealt with in the section entitled Disc Filing System. CHANGES IN THE OPERATING SYSTEM - B In general, this has been kept close to the operating systems of the BBC range, so that well-behaved application programs should have a high degree of portability. Accessing the following (e.g. CALL &FFF1, =USR(&FFF1) in a BASIC program or JSR &FFF1 from Assembler) should all work with the emulator invoked: A OSWRCH OSRDCH OSASCI OSNEWL B OSFILE OSARGS OSGBPB OSFIND OSBGET OSBPUT B OSBYTE's (including *FX equivalents in BASIC) B OSWORD's (A=&0 to A=&D) A OSCLI The following will not work: E GSINIT GSREAD OSEVEN E Interrupt and event handling routines in application packages are also probably not going to work. Thus, although defining the BREAK key with a command string should function as normal, code associated with Break protection is unlikely to work (using *FX 247,9 will fail). BBC is an abbreviation of British Broadcasting Corporation. Acorn is a trademark of Acorn Computers Limited. Econet is a registered trademark of Acorn Computers Limited. Archimedes is a trademark of Acorn Computers Limited. C Acorn Computers Limited 1987