A DRAGON IN THE TUBE Electronics & Computing Monthly, August 1985 Yes, a Dragon can be used as a 6809 second processor for the BBC micro. Huw Jones' simple interface opens up wider applications, a better operating system [better? in what way?], and more memory to the BBC user. The BBC micro, while undoubtedly a very powerful computer, has a number of serious drawbacks. Apart from the obvious problems caused by the chronic shortage of memory when using the high resolution screens, Acorn's DFS does not bear close scrutiny when compared to systems running a proprietary DOS such as CP/M. [DFS is not an operating system, and CP/M is not a DOS. CP/M should be compared to the BBC MOS, not to DFS, DFS should be compared to CP/M's BDOS, as and such is miles better.] Such operating systems can boast a wealth of development software such as high level languages and cross assemblers. [The BBC has a wealth of development software, including high level languages and cross assemblers.] Utilities written for the BBC micro often try their best to 'make do' but rarely succeed [do you walk around the world with your eyes closed?] in overcoming the lack of available memory (BCPL is a case in point). Having highlighted the failings of the beeb, what are the positive aspects of the computer's design? Unquestionably, it is a superb example of digital design. The operating system software is excellent too, but there is rather a lot of it - 32K of ROM just to run BASIC is a bit excessive. [It's not 32K, it's 16K, and it's not 'just' to run BASIC. It's to run whatever you want to run. Half the MOS is the VDU drivers, almost half a tape filing system, the rest is core support to allow anything else to use the system. What should they get rid of?] A major bonus is that all of the interfaces found as optional extras on many home computers are fitted as standard on the beeb, or can simply be installed by adding a few components to the computer's main PCB. These interfaces include the floppy disk interface controller, printer port, RS423 port, Analogue to Digital converters and no less than three system expansion ports: the 1MHz bus, the user port and the TUBE. This list excludes the obvious attractions of an 80 x 24 text display which is available from any of three video outputs. A second processor complements the BBC micro by taking over all the computation heavy workload leaving the BBC to concentrate on implementing the I/O. While there are many commercial second processors available, including Acorn's own 6502 and Z80 designs, this project makes use of a Dragon computer to offer a 6809 second processor system. Enough has been said in praise of the 6809 MPU and it is a matter of regret that the Dragon never achieved the commercial success that it deserved. The designers of the computer did themselves no favours by restricting the display to a 32 x 16 upper case text only but they did build in 64K of RAM and a bus expansion facility. This is exactly the specification expected of a 6809 second processor. Accepting that we are to use a Dragon computer as a second processor, what do we do with it? A simple approach would be to use the BBC micro as an extension of the Dragon's I/O capability. This could be accomplished by attaching appropriate software onto the Microsoft BASIC 'hooks', most existing Dragon software couid be made to operate in a smart 80 column mode with disks. Most people would however, not unreasonably, expect a 6809 second processor to run a 6809 operating system - either OS9 or FLEX. ----BOX---- THE FLEX OS The FLEX operating system originated in the United States. Written by TSC, FLEX is a powerful OS designed make the best use of the features of the 6809 MPU. A wide range of applications packages is available for FLEX systems. These range from software development aids to a full suit of general and business software. Such packages include a variety of word processors; Dynacalc, a powerful spreadsheet system; the RMS data management system; and specialised business software such as cash and VAT and purchase ledger packages. Compusense offers full support for FLEX in the UK and via its contacts in the USA has access to a vast number of applications packages. Compusense, PO Box 169, 286D Green Lanes, Palmers Green LONDON, N13 5XA. ----BOX---- The former is an excellent package supporting multi-tasking (great!) and multi-users (impractical in a floppy disk based system). Unfortunately, with the exception of Dragon Data's version, OS9 is very expensive. Conversely, FLEX has a broader market and is generally lower in cost with much more software in existence. It is well documented, available in a wide variety of standard disk formats, simple to use and convenient for development work. Both operating systems are capable of being customised for new hardware configurations, the FLEX Programmer's Manual being very helpful in this respect. All things considered, it had to be FLEX. A final nail in the coffin of OS9 is the fact that the Dragon version is supplied on double density disks which cannot be read by the 8271 FDC in the beeb. For those who possess a BBC model B with Acorn's DFS and dual disk drives then adding this second processor will not incur much expense apart from the purchase of the FLEX licence, ie a copy of the DOS. Ignoring the low component cost of the TUBE interface itself, the only other item required is the Dragon computer. A Dragon 64 is ideal but a Dragon 32 can be used providing that it is fitted with 64K of addressable RAM. How it works Despite all the mysterious references to the TUBE in the BBC User Guide, it is merely an extension of the, CPU bus, brought 'raw' to the 40 way IDC TUBE plug. A TUBE select signal is provided which becomes active in the range $FEE0-$FEFF. External hardware is required before the TUBE can do anything at all and even then any data transfer must rely heavily on software; Acorn's answer was to produce a custom ULA to interface the micro to its co-processor whilst other designs have used the simple expedient of using two back-to-back VIAs. This design goes one better and implements a 2MHz TUBE interface with just a single 8255 PPI and a few support TTL chips, The complete circuit diagram of the TUBE interface is shown in Figure 1. Connector CON1 is a 40 way IDC header which mates with one end of a 40 way ribbon cable terminated at both ends by 40 way IDC sockets. The other end plugs into the TUBE connector of the BBC micro. Keep the cable short, say 2ft maximum. CON2 is a 0.1" pitch double side edge connector which plugs into the Dragon cartridge port, IC4 is an LS245 bi-directional buffer which isolates the 8255 from the 6502 data bus until the TUBE select goes low (SHEILA, offset E0-FF). Similarly IC5, an 81LS95, buffers the 6502 control signals. The outputs from this chip, and hence IC4, are only enabled when both the BBC and the Dragon are powered up. If the Dragon is on but the BBC off then IC5 and IC4 have no supply rail whilst if conditions are reversed, Q2 will be off and its collector will pull pin 19 of IC5 high. In this tri-state condition, IC4 is also disabled due to R2 pulling pin 19 high. The correct power-up sequence is to first switch on the BBC micro, followed by the Dragon when the beeb has made its customary 'ready' tone. As part of the BBC computer's initialisation procedures, the computer's MOS polls for the presence of a second processor and will perform a TUBE set-up routine if it decides that there is one. This assumes Acorn's own ULA to be fitted. In the absence of formal documentation [so, the Advanced User Guide, the New Advanced User Guide, the BBC OS Reference Guide, Inside the BBC MOS and others don't count as documentation?] and the lack of inclination to disassemble the BBC ROM [you can't even be bothered disassembling 800 bytes of code?], it has been presumed that the BBC micro acknowledges the presence of a second processor if, and only if, it reads a $FF at $FEE0 immediately after a hard reset. Until its mode of operation is configured by the BBC, the 8255 will be in its default, high-impedance input state for ports A, B and C. Thus random sampling of the TUBE (port A) by the BBC will return the instantaneous value of the 6809 data bus which could be anything. If the TUBE check is made before the Dragon is switched on however, the 6502 is forced to read all zeroes due to the pull-down action of RPK1. ---BOX--- BUYING A DRAGON The cheapest Way to obtain a Dragon computer is via the 'For Sale' columns of specialist computer magazines. Prices for the machines can vary greatly but it should be possible to buy a secondhand Dragon 64 for under £100. Remember though, it is necessary to use a 64K computer in the second processor project. There are many 32K machines offered for sale but these will not be suitable unless fitted with an extra 32K of RAM (an article describing this conversion is scheduled for a future issue of Electronics and Computing). The alternative is to buy a new machine via Compusense, the UK distributor of Dragon products. The company can be reached on 01 882 0681. The price of a 64 is £195 inclusive of VAT. ---BOX--- The Intel 8255 is a popular peripheral, often used in straightforward control applications. It has two 8-bit ports, A and B, and two nibble-wide ports, C lower and C upper. These can be configured on a group basis, as either input or output. This operation only involves writing to the appropriate registers within the 8255. This method of I/0 is known as mode 0. Mode 1 offers the facility for operating port A in either input or output with handshaking functions built-in to three lines of port C. An extension of this principle is mode 2 whereby port A is suitable for bi-directional data transfer with five lines of port C used for the handshake protocols. This indeed is the mode used here, set up by the BBC writing $E2 to the 8255 control register. Figure 2. TUBE data transfer Figure 1. TUBE interface circuit diagram Timing diagram for a typical data transfer is shown in Figure 2. Assume that the 6809 wishes to output a character to the BBC micro through the TUBE. It first writes the ASCII code to $FF40 which is decoded via IC8b, half an LS139, which produces a low pulse on the STB (PG4) input of the 8255 just as the data appears on the data bus at port A. This effectively latches the data into the 8255 and sets IBF (PCS) bit in the 8255 internal port C status register which signifies an input byte is ready. The 6502 detects this by polling $FEE2. An output, IBF, mirrors the status of this bit to the 6809, which tests its state by reading from $FF48. An LS251 data selector, IC7, passes IBF to D7 of the Dragon data bus. When the BBC acknowledges the character by reading the port A register, IBF automatically returns to the idle state (low) and the TUBE is available for further transfers. Overrun is prevented by the 6809 software which must always check IBF before releasing a character to the BBC. For transfers in the opposite direction, the 6502 writes a data byte to the 8255 port A register ($FEE0) which is loaded into the 8255 output buffer and sets OBF (PC7) low to indicate to the 6809 that a character is pending. Again, the 6502 can monitor the current state of this output through the 8255 port C register. The Dragon reads the status of OBF from $FF49, recognising that a byte is waiting if it returns a positive value (below $80). It fetches the byte by reading from $FF41 which puts a low strobe pulse on ACK (PC6) to enable the 8255 output buffer which places the byte onto the second processor data bus via port A. INTRA (PCS) is an interrupt output from the 8255, linked to the 6502 IRQ line by Q1, an open-collector inverter. An interrupt could be made to occur on receipt of an incoming byte or when a character output sequence has completed. With this scheme, port B and three lines of port C are redundant which suggests an auxiliary data transfer channel could be implemented. In fact a message port has been incorporated within the design, the only cost penalty being two LS chips. Transfer of data through port B can occur in either direction but the 6502 must always configure the mode of port B prior to the change of data direction. An output is assigned, MSDIR (PC1), which informs the 6809 whether port B is currently available for read ($FF58) or write ($FF50) and controls the OE, pin 1, of IC9, an LS373 latch used for data from the 6809 to the BBC. No conflict thus occurs with IC10, another 81LS95, which buffers port B data in the opposite direction until enabled via pin 1. A pull-up resistor, R3, ensures the LS373 is disabled whilst the 8255 is in its post-reset state. MSGDIR is tested by the 6809 through polling $FF4B. Another port C (PCO) is designated a 6502BUSY output, sampled on the second processor side by reading $FF4A- if positive then the 6502 is free. Note that it is the 6502 software which controls this signal. At the moment, MSGDIR and 6502BUSY are used to: (a) pass command completion semaphores from the 6502 to the 6809. (b) synchronise the second processor to the host when it is engaged in processing a time consuming command such as reading from a disk. the combinational logic, comprising gates 1 a, 2c, 2d, 3a and 3d, convert the 6502 bus control signals into versions suitable for the 8255. It is important that a 5MHz part is used for the latter device in order to run at the 2MHz rate of the TUBE. Link options are provided so that incoming data bytes could be serviced by interrupts on both CPUs. These are currently left open-circuit since interrupt driven transfers offer no substantial benefits and present some awkward problems on the 6502 side. A 2716, IC11, is used to hold the 6809 FLEX BOOT software which is copied across to RAM at $F800 in map type 1. The circuit around, and including IC8, generates the various signals needed to route any data and ensures certain addresses are read-only or write-only as appropriate. A 'power-on' LED is included for completeness. NEXT MONTH TUBE software and how to customise FLEX to operate across the TUBE and details of how to obtain the pcb and kit of parts. A DRAGON THE TUBE Electronic & Computing Monthly, September 1985 Huw Jones' 6809 second processor for the BBC looks suspiciously like a Dragon 64. It should do because it is. This month he explains the software interface between the two machines. The software controlling operation of the second processor comes in two sections. The programs are written in assembly language, one in 6502 code, the other in 6809. The main task of the supporting software is to enable the BBC micro to maintain constant communication with the 6809 processor and to interpret its command requests into I/O tasks. A simplified flow diagram is shown in Figure 1. Initialisation entails selecting the correct screen mode and colour (yellow and black), flushing all buffers, enabling the console for input and configuring the 8255 via its control register at $FEE3. At this point the BBC 'escape' key is disabled. Finally, a prompt is displayed on the BBC's screen and the computer waits for the user to press a key before it proceeds into the main loop proper. This pause allows the Dragon to be turned on at the correct time. ---BOX--- 'The main task of the supporting software is to enable the BBC to maintain constant communication with the 6809 processor'. ---BOX--- The software continually scans the selected input stream, normally the keyboard, and any characters found are dispatched to the 6809. FLEX will automatically echo back any character through the TUBE, at which point the BBC micro will pick it up and display it on the screen or send it to the currently selected output stream. This sequence of events applies to all ASCII characters in the range 0-$7F; codes above this are reserved for second processor system calls. When the 6809 sends such a call, the 6502 software will execute the associated commands, listed in Table 1. When a command commences, 6502BUSY goes actibe low, and the 6502 only returns it high when the execution phase is complete. With some of the commands, additional parameters must accompany the code byte in the order stated. Similarly, a number of commands return a variable number of values to the 6809 and/or an indication of successful completion via the message byte, otherwise the message port is cleared. The assembled object code occupies approximately 3K and is booted from disk by typing: *GOFLEX which loads ans starts the software at $1E00. A set of jump tables located at $1E03 to $1E35 are reserved for commands codes $80 to $8F and $B1. These are currently not used and are reserved for cursor control and a user defined command respectively. Any specific I/O function can be added to the 6502 code by patching in an extende jump at the relavant table entry and appending the code to the main program. Any code added in this way must end with an RTS instruction. There are four tasks which the 6809 software must perform: * Set up 64K map type 1 mode. * Boot the FLEX system file from disk. * Initialise the FLEX parameters for the second processor system and start the FLEX kernel. * Handle all I/O and disk access calls from FLEX On power-up. map type 0 is selected and the boot software appears in EPROM at $C000. If locations $C000 and $C001 contains the values $44, $4B (ASCII 'DK' - somebody's initials at Microsoft?) then the software will autostart, otherwise, the boot procedure can be started by typing: EXEC &HC002 The program first copies the contents of the BASIC ROMs and itself into the lower 32K of RAM before transfering control to the image of itself that it has just made. From this safe place, the SAM in the Dragon is switched to map type 1 which 'tacks on' another block of 32K RAM at $8000-$FEFF. The program image now proceeds to copy itself to $F800 onwards and the BASIC copy is placed back at $8000 from whence it originally came. Program control now transfers to the second image of the boot software and the system is ready to proceed to load FLEX. If this sounds complicated, imagine the problems of debugging the software across the map switching during the development of the project. Conventionally, a FLEX system boots itself from a short disk-resident routine. This implies that a FLEX system disk is usually hardware-specific. To circumvent this obstacle, the complete boot procedure is contained within the boot EPROM and the system should (in theory) be able to use any linked system disk. Briefly, the boot program loads in the dirst sector on the system disk and checks that it has been 'linked' to the start of FLEX (a file named FLEX.SYS). If so, it locates this file and retrieves it sector by sector via the TUBE and places the code in the allotted space $C000-$DFFF. When done, the disk driver and I/O jump tables within FLEX are modified to point to the routines resident within the boot software and then suitable parameters are set for the BBC's keyboard. Control is then passed to FLEX. All FLEX hardware calls are now forced through the boot software rotuines which activate the various TUBE software requests. So that any FLEX untility may have access to the routines that servce the TUBE (besides the standard FLEX I/O calls) a set of indirection operators is supplied at $FEF0-$FEFF and explained in Table 2. These greatly simplify the task of including any dedicated second processor commands within a FLEX utility and will remain fixed. In order to fully integrate this new FLEX system, several new utilities must be prepared. A disk formatter is required to initialise a blank disk for use within the second processor arrangement. To keep things as simple as possible, the 'raw' format procedure, that is the inscribing of the ID and data fields on the disk by the 8271, is performed as a TUBE command in the BBC software, code byte $AF. The remaining operations to be carried out are accomplished by a custom FLEX utility called BBCFORM which supercedes the standard NEWDISK utility. This includes generating the directory system record and free sector chain which is the very cornerstone of FLEX. To accommodate any type of disk drive, the utility first prompts the user to enter various parameters before entering the BBC format primitive. All hard copy is obtained from the BBC printer port. Command codes $94 and $95 are used to select and terminate output to the MOS printer buffer. a new line printer driver has been prepared for the second processor which incorporates a custom version of the PRINT.SYS file required by FLEX XBASIC. The new command LPR replaces the original FLEX P utility. Due to the vagaries in the map type 1 address decoding, the 6809 vectors are still obtained from the top of one of the BASIC ROMs. These vectors point to service routine jumps at $100-$1111, which FLEX expects to be available for general purpose use. If FLEX writes 'garbage' prior to an interupt occuring, then spectacular crashes can ensue. In practice, the situation is nothing like as nasty as it appears. Interrupts are permanently disabled in the second processor (they are not required, and printer spooling is not supported). In addition, slightly amended version of the few oft-used FLEX utilities that could corrupt the stack have been prepared. These offer added security by regarding $600 as the bottom of memory, just above the screen RAM. Furthermore, a FLEX utility called PRESVEC restores the service calls to point to routines in the boot software. This utility should be called before or after any FLEX software that demands interupts. It should be stressed that none of these special precautions have been found necessary when using prototypes of the system, though if using a FLEX Debug package, interupts should be disabled before using the trace function by setting CC to $50. Figure 1. Simplified flow diagram of the software TABLE 1. BBC command codes for FLEX Command Parameters Function 80 CURSOR EDIT 81 " " 82 " " 83 " " 84 " " 85 " " 86 " " 87 " " 88 " " 89 " " 8A " " 8B " " 8C " " 8D " " 8E " " 8F " " 90 TRACK, SECTOR, DATA(256)> read disk sector 91 TRACK, SECTOR, DATA(256)< write disk sector 92 DRIVE NUMBER select drive 93 init drive 94 enable printer o/p 95 disable printer 96 enable vdu 97 disable screen 98 enable RS423 o/p 99 disable RS423 o/p 9A CHANNEL, SOUND GEN LIST generate sound 9B VDU CODE, VDU LIST vdu driver 9C CHANNEL, A/D> (MSB) read a/d value 9D STATUS> (NZ=CHAR READY) check keyboard status 9E STATUS> (NZ=CHAR READY) get RS4213 i/p status 9F STATUS> (NZ=BUF EMPTY) check RS423 o/p status A0 OFFSET, BYTE> read one byte from FRED A1 OFFSET, BYTE< write one byte to FRED A2 OFFSET, BYTE< read one byte from JIM A3 OFFSET, BYTE> write one byte to JIM A4 OFFSET, BYTE< read one byte from SHEILA A5 OFFSET, BYTE> write one byte to SHEILA A6 abort FLEX (not used) A7 MSGDIR=6809 to BBC A8 MSGDIR=BBC to 6809 A9 DISK ERROR CODE> request disk error info AA WP STATUS> ($B=WR PROT) request disk WP status AB ADDR(H,L), CNT(H,L), DATA transfer data to BBC memory AC enable RS423 i/p AD disable RS423 i/p AE BAUD RATE CODE set RS423 baud rate (I/O) AF NO. OF TRACKS format blank disk B0 A REG, X REG, Y REG perform OSBYTE call B1 user defined function NOTES 1. > direction of byte is BBC to 6809 2. < " " " " 6809 to BBC 3. Unless shown, parameter byte direction is '<' 4. Command $AB expects 'CNT' bytes from 6809 5. Unless shown, parameters as per BBC MOS *FX calls TABLE 2. 6809 boot software TUBE vectors Location Function FEF0 reserved for future use FEF2 initialise TUBE interface FEF4 check TUBE status (NZ if busy) FEF6 set MSGDIR 6809 to BBC FEF8 set MSGDIR BBC to 6809 FEFA load control byte from TUBE FEFC check command completed (Z=OK) FEFE issue BBC command (code in A) How to get your second processor kit and software A complete kit of parts for the TUBE interface, together with detailed information regarding the contrstuction of the project is available from the Logic Shop at the address shown at the end of thie article. The system software will be made available from Compusense. After many weeks of hard use, the system has proved very reliable in operation and pleasant to work with. The BBC acts as an ultra-fast I/O so that screenfuls of text appear in next to no time. Disk accesses take marginally longer than if they were implemented by an FDC section on the 6809 side, but it is disk searches that consume by far the bulk of waiting time. Experiments with sector interleaving to improve the through put of the system have proved inconclusive. Although FLEX is workable with a single disk drive - just - the system really comes into its own with two, or more. If double-sided drives are installed, then Acorn's drive numbering convention effectively implements a four drive system which is very nice indeed! Communication with laboratory equipment such as EPROM blowers and emulators is possible through the BBC's RS423 port. A download function code $AB hes been built into the 6502 to exedite any data transfer required from the second processor. It is intended to develop a variety of peripherals for the system which will be driven by FLEX through the BBC's 1MHz bus. The Logic Shop Dunraven Plave, Bidgent, Mid Glamorgan Telephone 0656 2656 Will supply a complete kit of parts for the TUBE interface. Phone for details of price and availability. Compusense PO Box 169, 286D Green Lanes, London, N13 5XA. Telephone 01 882 0681 Will supply the system software. Phone for details of price and availability. Compusense can also supply Dragon 64 computers.