On Jul 25, 17:29, Derek Peschel wrote:
> Oops, sorry. I knew there were two FIFOs but I didn't realize they were
on
> one chip.
>
> What exactly are the MOS routines designed to offer the second processor?
> I know they can copy software over the Tube and do some relocation (and
> that the relocation was enhanced in the Master). But what are the
> functions/memory locations/etc. avaialble to each side?
To understand that, you need to have a little information about how the MOS
(Machine OS) works normally (without the Tube). The whole thing is based
on a very structured and comprehensive set of system calls which handle
everything a user, applications programmer, or sytems programmer would want
to do. The two best known are OSByte and OSWord.
OSByte is used to make system calls which take few parameters, which are
therefore passed in the registers: A holds the call number (determines
which OSByte function you want), and X and sometimes Y pass data. The
low-numbered calls mostly read or write a value in the OS variable space
(eg to set serial port parameters) and the high-numbered ones are
read/modify ones. Typically A holds the call number, X holds a value, and
Y holds a mask. The variable is ANDed with Y and EOR'd with X (so you can
set, clear, toggle, or leave unchanged any bit) and the old value is
returned in X.
OSWord is used for calls that need larger parameter sets. Here X and Y
contain the 32-bit address of a parameter block, which may be updated by
the call.
There are several other sets of calls, such as OSWrCh (write a character to
an output stream, eg screen or printer), OSFile (assorted filehandling
functions such as open or close a file, or read a file, a byte, a
directory, or whatever), OSCli (pass text to the comand line interpreter),
OSEven (generate an event - a software interrupt), etc.
Everythng is written to use these calls, and they work over the Tube. If
the call is initiated in the 2nd Processor, its ROM knows to pass it over
to the I/O processor (the 6502 in the Beeb). If it's something that
involves transferring a memory block, such as the OSWORD that reads a raw
disk sector into a buffer, the top part of the 32-bit address determines
whether the address refers to I/O processor address space or the 2P address
space. The 2nd Processor ROM only needs to know how to pass parameters to
the I/O processor, how to use the FIFOs to transfer data, and be able to
jump to an address in its own memory space.
> And how does the
> whole thing get booted (and then stay running)?
At reset, the MOS offers a series of service calls to each sideways ROM in
turn (ie, it calls each ROM in turn, with a certain "reason code" in the A
register). These calls give each ROM the opportunity to register itself as
a language, a filing system, or a service provider. The ROM containing the
Tube code accepts some of these calls and initialies the Tube interface.
Meanwhile, if there's a second processor on the other side of the Tube,
its ROM initialises its side, and when asked by the 6502 side, tells the
6502 what processor it is. Once the rest of the 6502 initialisation is
complete, it will go into a loop waiting for system calls from the other
side. If the other side is another 6502 (there's a 3MHz 65C02 2nd
Processor), it will usually ask for a copy of the current language, which
may be relocated to the top of memory, or if it's a Z80, it will ask the
I/O processor to give it the contents of the first sector of a disk (and
boot CP/M).
> Also, ULA = Uncommitted Logic Array, a semi-custom PLA-like thing. Was
> it made by Ferranti? Acorn used a few different ULAs and so did some
other
> vendors. I think Sinclair was one.
Yes, it was Ferranti. A ULA was an array of gates with no final
metallisation layer pre-defined; the designer would specify the
interconnections between the gates (rather like drawing a PCB layout) and
that was turned into a mask which was used to lay down the metallisation in
the final stages of wafer manufacture.
> And MOS = Machine OS = the ROM routines in the BBC, including the
abstract
> filesystem interface but not any filesystems (which could be added or
> removed as desired) and an astonishing number of places for the user to
> extend the code.
--
Pete Peter Turnbull
Network Manager
University of York
Received on Thu Jul 26 2001 - 07:57:55 BST